大型项目中Autofac的使用：全局容器是否为可行方案？

嘿，很高兴你在探索大型项目里的Autofac用法——全局容器确实是基础，但我们可以把它拆解得更优雅、更易维护，尤其结合你提到的WCF场景和项目模块结构。下面我给你梳理一套落地的架构思路：

结合你的项目结构，我们可以把Autofac的注册逻辑和模块职责绑定，避免把所有注册堆在启动入口：

• Bootstrapper：作为容器构建的入口，负责整合所有模块的注册逻辑，不包含具体的服务注册代码
• Core：定义全局通用的接口、工具类，以及Autofac的基础扩展（比如自定义生命周期、注册约定）
• DataAccess/Data：注册数据访问层的依赖（DbContext、Repository等）
• Business/Managers/Engines：分别注册对应层级的业务服务（比如Engines处理核心业务逻辑，Managers做协调调度）
• Hosts/TestHost：仅负责启动容器、初始化宿主（比如WCF服务），不参与具体服务注册

不要在Bootstrapper里写所有注册代码，而是让每个业务模块定义自己的Autofac.Module，这样模块的依赖变更时，只需要修改自身的注册逻辑。

举个例子，DataAccess模块的注册类：

public class DataAccessModule : Module
{
    protected override void Load(ContainerBuilder builder)
    {
        // 注册DbContext，用InstancePerLifetimeScope适配WCF的请求生命周期
        builder.RegisterType<MyDbContext>()
               .AsSelf()
               .InstancePerLifetimeScope();
        
        // 批量注册Repository：所有实现IRepository接口的类
        builder.RegisterAssemblyTypes(typeof(DataAccessModule).Assembly)
               .Where(t => t.GetInterfaces().Any(i => i.IsAssignableFrom(typeof(IRepository<>))))
               .AsImplementedInterfaces()
               .InstancePerLifetimeScope();
    }
}

同理，Business模块也可以写一个BusinessModule，注册业务服务：

public class BusinessModule : Module
{
    protected override void Load(ContainerBuilder builder)
    {
        // 注册业务服务，比如按约定注册所有以Service结尾的类
        builder.RegisterAssemblyTypes(typeof(BusinessModule).Assembly)
               .Where(t => t.Name.EndsWith("Service"))
               .AsImplementedInterfaces()
               .InstancePerDependency();
    }
}

然后在Bootstrapper里整合这些模块：

public static class Bootstrapper
{
    public static IContainer BuildContainer()
    {
        var builder = new ContainerBuilder();
        
        // 注册所有业务模块的Autofac Module
        builder.RegisterModule<CoreModule>();
        builder.RegisterModule<DataAccessModule>();
        builder.RegisterModule<BusinessModule>();
        builder.RegisterModule<ManagersModule>();
        builder.RegisterModule<EnginesModule>();
        
        return builder.Build();
    }
}

WCF有自己的实例生命周期管理，直接用全局容器可能会导致资源泄漏，所以要结合Autofac的WCF扩展来做：

在Hosts的Main方法里，我们可以这样初始化：

static void Main(string[] args)
{
    // 构建容器
    using var container = Bootstrapper.BuildContainer();
    
    // 用AutofacServiceHost替代原生ServiceHost，让Autofac管理WCF服务实例
    var serviceUri = new Uri("net.tcp://localhost/MyWcfService");
    using var host = new AutofacServiceHost(typeof(MyWcfService), container, serviceUri);
    
    // 添加服务终结点
    host.AddServiceEndpoint(typeof(IMyWcfService), new NetTcpBinding(), "");
    
    // 启动服务
    host.Open();
    Console.WriteLine("WCF服务已启动，按任意键停止...");
    Console.ReadKey();
    
    host.Close();
}

这里的关键是用AutofacServiceHost，它会把WCF的实例创建权交给Autofac，这样你的WCF服务类就可以通过构造注入获取依赖：

public class MyWcfService : IMyWcfService
{
    private readonly IOrderManager _orderManager;
    
    // 构造注入依赖，不需要手动从容器获取
    public MyWcfService(IOrderManager orderManager)
    {
        _orderManager = orderManager;
    }
    
    public void ProcessOrder(OrderDto order)
    {
        _orderManager.HandleOrder(order);
    }
}

虽然你可以在Core里定义一个全局容器静态类，但强烈不推荐直接在业务代码里用Container.Resolve<T>()，这会导致代码耦合到Autofac，也不利于测试。

正确的做法是：

• 所有业务类通过构造函数声明依赖
• 只有启动层（Hosts/TestHost）持有容器实例，负责初始化宿主和顶级服务
• 如果确实需要在特殊场景下获取容器（比如静态工具类），可以用Autofac的ILifetimeScope注入，而不是全局容器

TestHost可以复用Bootstrapper的逻辑，但通过替换模块来注入模拟依赖：

public static class TestBootstrapper
{
    public static IContainer BuildTestContainer()
    {
        var builder = new ContainerBuilder();
        
        // 注册基础模块
        builder.RegisterModule<CoreModule>();
        
        // 注册模拟的DataAccess模块，比如用内存数据库的DbContext
        builder.RegisterModule<MockDataAccessModule>();
        
        // 其他模块正常注册，或者替换需要模拟的服务
        builder.RegisterModule<BusinessModule>();
        
        return builder.Build();
    }
}

这样在测试时，你可以用TestBootstrapper构建容器，轻松替换掉真实的数据库依赖，用模拟对象做单元测试或集成测试。

这套架构的核心是模块化注册+分层职责，既保留了全局容器作为依赖注入的核心，又避免了把所有逻辑堆在启动入口，同时适配了WCF的特殊场景。每个模块只关心自己的依赖注册，业务代码完全通过构造注入获取依赖，既解耦又易于维护和测试。

内容的提问来源于stack exchange，提问作者cantdoanything33