我已经阅读了多篇关于是否在构造函数中执行资源密集型操作的文章。他们中的一些人说,如果它不影响SRP或可测性,那么它就没问题了。我想对这种情况的最佳实践提出意见。
我遵循ASP.Net WebApi2项目中提到的here的组合根原则,我的控制器已经注入了它们的依赖对象。我想注入整个容器,并且可以使用任何依赖项,而不是只注入一些依赖项。我有这个类设计,我在构造函数中设置容器属性。我不知道这是否属于不良做法。
.Build()
如上所述,在构造函数中调用AppContainer
是不好的设计?我想这样做,以便在创建实例时初始化public class HomeController : ApiController
{
private readonly IBusiness _bus;
public HomeController(IBusiness bus)
{
_bus = bus;
}
的属性,而不是等待调用某些方法使属性保持值。
现在在我的控制器中而不是像这样的
public class HomeController : ApiController
{
private readonly IAppContainer _container;
public HomeController (IAppContainer container)
{
_container = container;
}
我可以拥有这样的东西并直接暴露容器。这样,每次我需要注入新的依赖项时,我的控制器的构造函数定义都不会改变。
restaurant
答案 0 :(得分:1)
如上所述,在构造函数中调用.Build()是不好的设计?
一般情况下,不建议您在构造函数中做很多事情。
另外,我建议您根本不使用AppContainer
课程。您只需使用AppContainer
类包装容器并将其用作服务定位器which is an anti-pattern。
您的类应该在构造函数中显式声明它们的依赖项,就像在HomeController
的第一个示例中那样。
如果你设计的类考虑到SOLID principles,那么你的类很小,不需要很多依赖,所以你几乎不需要添加新的依赖项。
请注意,拥有太多依赖项(> ~3)可能表示您违反了单一责任原则and is considered a code smell。