为DI无关库创建Catalog：如何在无DI的ASP.NET WebForms遗留项目中调用DI友好内部库

我之前帮团队处理过几乎一模一样的场景——既要维护类库的SOLID和DI友好性，又要给老系统留好便捷的调用入口，下面是几个经过实践验证的方案：

1. 先守住类库的DI友好底线 #

首先要确保你的类库核心逻辑完全遵循构造函数注入，绝对不要在内部用new实例化依赖，也别用Service Locator模式。比如类库的核心服务应该是这样的：

public class OrderProcessor : IOrderProcessor
{
    private readonly IOrderRepository _repo;
    private readonly ILogger _logger;

    // 构造函数注入依赖，类库本身不关心依赖从哪来
    public OrderProcessor(IOrderRepository repo, ILogger logger)
    {
        _repo = repo ?? throw new ArgumentNullException(nameof(repo));
        _logger = logger ?? throw new ArgumentNullException(nameof(logger));
    }

    // 核心业务逻辑
    public void ProcessOrder(Order order) { /* ... */ }
}

这样DI友好的设计，新应用直接注册到容器就能用，而遗留场景我们用“门面”来封装依赖组合。

2. 创建DI无关的Catalog门面 #

你提到的Catalog对象，本质就是组合根（Composition Root）的简化版本——它作为类库的入口，帮遗留应用处理依赖的实例化，同时不破坏类库的DI设计。

实现思路： #

• Catalog只暴露静态方法或实例方法，返回类库的核心服务实例；
• 内部默认创建依赖的“默认实现”，同时预留扩展点允许自定义依赖；
• 绝对不要让Catalog变成全局服务容器，它只是给无DI场景提供便捷入口。

示例代码：

public static class Catalog
{
    // 可选：存储自定义依赖的静态字段（线程安全要注意）
    private static IOrderRepository _customRepo;
    private static ILogger _customLogger;

    // 初始化方法：允许遗留应用传入自定义依赖
    public static void Initialize(IOrderRepository repo = null, ILogger logger = null)
    {
        _customRepo = repo;
        _customLogger = logger;
    }

    // 入口方法：返回核心服务实例
    public static IOrderProcessor CreateOrderProcessor()
    {
        // 优先用自定义依赖，没有则用默认实现
        var repo = _customRepo ?? new DefaultOrderRepository();
        var logger = _customLogger ?? new DefaultLogger();
        
        return new OrderProcessor(repo, logger);
    }
}

3. 适配遗留ASP.NET WebForms的调用方式 #

WebForms没有内置DI容器，我们可以结合它的生命周期来使用Catalog：

方式一：全局初始化，页面直接调用 #

在Global.asax的Application_Start里做一次初始化（如果需要自定义依赖的话）：

protected void Application_Start(object sender, EventArgs e)
{
    // 如果遗留应用有自定义的Repository或Logger，在这里传入
    Catalog.Initialize(repo: new LegacyOrderRepository());
}

然后在WebForms页面里直接调用：

protected void Page_Load(object sender, EventArgs e)
{
    var processor = Catalog.CreateOrderProcessor();
    processor.ProcessOrder(new Order { /* ... */ });
}

方式二：利用HttpContext存储实例（适合有状态的服务） #

如果你的服务需要和请求生命周期绑定，可以把实例存在HttpContext.Current.Items里：

public static class Catalog
{
    public static IOrderProcessor GetOrderProcessor()
    {
        var context = HttpContext.Current;
        if (context == null) throw new InvalidOperationException("必须在Web上下文调用");

        if (!context.Items.Contains("OrderProcessor"))
        {
            var repo = new DefaultOrderRepository();
            var logger = new DefaultLogger();
            context.Items["OrderProcessor"] = new OrderProcessor(repo, logger);
        }

        return (IOrderProcessor)context.Items["OrderProcessor"];
    }
}

这样每个请求都会有一个独立的服务实例，避免线程安全问题。

4. 兼顾新老应用的平衡 #

• 对于用DI+TDD的新应用：他们完全不需要Catalog，直接把类库的服务注册到自己的DI容器即可（比如Autofac、Microsoft DI），类库的DI友好设计完全兼容；
• 对于遗留应用：Catalog提供了零配置的调用方式，同时允许他们通过Initialize方法自定义依赖，满足特殊需求；
• 维护成本：Catalog的逻辑很简单，只需要和类库的核心服务同步更新构造函数即可，不会增加太多维护负担。

关键注意事项 #

• 不要在Catalog里加入复杂的逻辑，它只负责依赖组合；
• 避免用静态状态存储可变数据，如果必须存，一定要保证线程安全；
• 类库的核心逻辑永远不要依赖Catalog，保持两者完全解耦。

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