在构造函数中初始化容器的 Autofac

本文关键字：Autofac 初始化 构造函数 | 更新日期: 2023-09-27 18:30:41

我已经阅读了多篇关于是否在构造函数中进行资源密集型操作的文章。他们中的一些人说，如果它不影响SRP或可测试性，那就没问题了。我想就这种情况的最佳实践发表意见。

我遵循 ASP.Net WebApi2项目中提到的组合根原则，并且我的控制器已注入其依赖对象。我不是只注入几个依赖项，而是要注入整个容器并具有任何可用的依赖项。我有这个类设计，我在构造函数中设置容器属性。我不知道这是否属于不良做法。

public class AppContainer : IAppContainer
{
    private readonly ContainerBuilder _builder ;
    private IContainer _container ;
    public AppContainer ()
    {
        _builder = new ContainerBuilder();
        _builder.RegisterAssemblyModules(_assembly);
        _container = _builder.Build();
    }
    public ContainerBuilder ContainerBuilder
    {
        get { return _builder; }
    }
    public IContainer Container
    {
        get { return _container;}
    }
}

如上所述在构造函数中调用.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;
    }

在构造函数中初始化容器的 Autofac

调用 .如上所述在构造函数中构建（）？

通常，不建议您在构造函数中做很多事情。

另外，我不建议您使用 AppContainer 类。您只需使用 AppContainer 类包装容器，并将其用作反模式的服务定位器。

您的类应该在构造函数中显式声明它们的依赖项，就像在 HomeController 的第一个示例中一样。

如果你在设计类时考虑到 SOLID 原则，那么你的类会很小，不需要很多依赖项，所以你几乎不必添加新的依赖项。

请注意，依赖关系过多 （> ~3） 可能表明您违反了单一责任原则，并被视为代码异味。

相关文章：