注入ILifetimeScope是否为最佳实践？如何Mock其Resolve方法？

问题场景 #

你当前的代码通过构造函数注入ILifetimeScope，并在方法内解析依赖：

private readonly ILifetimeScope _container;

public MyService(ILifetimeScope container)
{
    _container = container;
}

private void Save()
{
    using (var scope = _container.BeginLifetimeScope())
    {
        var rdb = scope.Resolve<IDatabase>();
        bool result = rdb.Save(name:"newAccount"); // 无法断言该结果
    }
}

单元测试时遇到ILifetimeScope.Resolve()无法Mock的问题，导致无法断言Save方法的执行结果，同时担心直接构造函数注入所有依赖会导致参数过多。

问题解答 #

1. 使用ILifetimeScope.Resolve()是否属于最佳实践？

这不是依赖注入的最佳实践，这种写法属于「服务定位器模式」，存在以下问题：

• 依赖关系不透明：从构造函数无法看出类实际需要哪些依赖，后续维护时难以快速理解类的职责边界
• 紧耦合到容器：类直接依赖DI容器的接口，导致脱离容器后难以测试，也限制了更换DI框架的可能性
• 违反依赖倒置原则：类没有依赖抽象的业务服务，而是依赖容器这个基础设施

如果觉得构造函数注入的依赖过多，正确的做法是拆分职责：将当前类的功能拆分为多个单一职责的小服务，每个服务只负责一个业务逻辑，这样每个类的依赖数量会大幅减少。如果存在一组需要协同工作的依赖，可以封装为「聚合服务」——创建一个新类来承载这组依赖，再将聚合服务注入到当前类中，避免构造函数参数臃肿。

2. 是否存在可以Mock Resolve()方法的方案？

有两种可行方案，但都属于临时妥协，长期建议重构为构造函数注入：

• Mock ILifetimeScope接口：利用Moq等Mock框架直接模拟容器和解析行为，示例代码如下：

// Mock IDatabase的Save方法
var mockDb = new Mock<IDatabase>();
mockDb.Setup(db => db.Save("newAccount")).Returns(true);

// Mock子生命周期范围
var mockScope = new Mock<ILifetimeScope>();
mockScope.Setup(s => s.Resolve<IDatabase>()).Returns(mockDb.Object);

// Mock根容器
var mockContainer = new Mock<ILifetimeScope>();
mockContainer.Setup(c => c.BeginLifetimeScope()).Returns(mockScope.Object);

// 初始化服务并调用方法
var service = new MyService(mockContainer.Object);
service.Save(); // 假设Save改为public以便测试

// 断言Save方法被正确调用
mockDb.Verify(db => db.Save("newAccount"), Times.Once);

• 使用测试专用容器：比如Autofac提供了测试模块，可以创建一个仅包含Mock依赖的测试容器，让类从这个容器中解析依赖。但这种方式更接近集成测试，而非纯单元测试。

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