ASP.NET Core类库项目中是否应该扩展IServiceCollection注册依赖？

你提到的两种注册方式都不违背「组合根」的设计原则，实际开发中更推荐各层类库内部封装自己的依赖注册扩展方法的方案，具体原因和逻辑如下：

核心原则澄清 #

组合根的核心定义是应用程序入口处统一触发所有依赖注册的逻辑位置，并非要求所有注册代码都必须写在Web项目的Startup/Program.cs单个文件中。只要所有注册逻辑最终都是在应用启动阶段、由入口项目统一触发执行，就完全符合组合根的设计要求，你看到的「组合根可以分散在同一个模块的多个类中」的描述就是这个意思。

两种方案的优劣对比 #

方案1：所有注册扩展都放在Web项目 #

• 适用场景：仅小型项目使用，各层类库不会被其他入口项目（比如后台作业服务、桌面端应用）复用，类数量少
• 优势：所有依赖注册逻辑集中在入口项目，排查注册问题时无需跨项目查找
• 劣势：类库复用时需要在每个新的入口项目重复编写注册代码，容易漏加、错加依赖，维护成本极高

方案2：各层类库内部封装注册扩展方法 #

• 适用场景：中大型项目，类库存在复用需求，各层职责划分清晰
• 优势：
  • 符合封装原则：类库使用者无需感知内部服务的注册细节，只需要调用类库暴露的扩展方法即可完成注册，比如业务层对外暴露AddBusinessLayer()方法，数据访问层对外暴露AddDataAccessLayer()方法，入口项目按依赖顺序调用即可
  • 避免重复编码：类库复用到其他入口项目时，直接调用对应扩展方法即可，无需重复编写注册逻辑
  • 完全符合组合根要求：这些扩展方法最终还是在Web应用的启动入口（即组合根位置）被调用，只是把同模块的注册逻辑封装到了模块内部，不存在违背设计原则的问题

最佳实践建议 #

• 每个逻辑层类库单独维护依赖注册的静态类，仅负责注册本层内部的服务，不要跨层注册其他层的依赖（比如业务层不要注册数据访问层的服务，由数据访问层自己管理内部注册逻辑）
• 如果层之间存在依赖（比如业务层依赖数据访问层），可以在业务层的扩展方法内部先调用数据访问层的扩展方法，入口项目只需要调用最上层的扩展方法即可，无需感知下层依赖
• 对于需要从入口项目传入参数的场景（比如数据访问层需要数据库连接字符串），可以将参数作为扩展方法的入参，示例如下：

namespace Architecture.DataAccess.DependencyExtension
{
    public static class DataAccessLayerDependency
    {
        public static IServiceCollection AddDataAccessLayer(this IServiceCollection service, string connectionString)
        {
            // 注册本层服务
            service.AddTransient<IOrderRepository, OrderRepository>();
            // 传入连接字符串配置上下文
            service.AddDbContext<AppDbContext>(opt => opt.UseSqlServer(connectionString));
            return service;
        }
    }
}

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