Unity容器下构造函数注入依赖的延迟初始化优化咨询

这是个很常见的依赖注入优化问题，尤其是当服务实例化成本很高（比如层级深、初始化耗时）的时候。下面给你几个可行的方案，你可以根据实际场景来选择：

1. 遵循单一职责原则拆分类 #

这是最推荐的长期解决方案，完全从根源上消除不必要的依赖实例化。你的类现在承担了多个职责：依赖IServiceA处理Method1，依赖IServiceB处理Method2和Method3。把它拆分成两个职责单一的类，每个类只注入自己需要的服务：

// 专门处理Method1的类，仅依赖IServiceA
public class Method1Handler
{
    private readonly IServiceA _serviceA;

    public Method1Handler(IServiceA serviceA)
    {
        _serviceA = serviceA;
    }

    public void Method1()
    {
        _serviceA.ExecuteOperation();
    }
}

// 专门处理Method2和Method3的类，仅依赖IServiceB
public class Method2And3Handler
{
    private readonly IServiceB _serviceB;

    public Method2And3Handler(IServiceB serviceB)
    {
        _serviceB = serviceB;
    }

    public void Method2()
    {
        _serviceB.DoTaskX();
    }

    public void Method3()
    {
        _serviceB.DoTaskY();
    }
}

优点：

• 完全符合SOLID的单一职责原则，代码职责清晰，维护性更强
• 彻底避免了不必要的服务实例化，调用Method2/3时完全不会涉及IServiceA
• 后续扩展新方法时，不会让原类变得臃肿

缺点：

• 需要调整调用方的代码，从原来的一个类调用改成两个类，不过这通常是值得的

2. 使用延迟注入（Lazy） #

如果暂时不想拆分类，可以用Unity原生支持的Lazy<T>来延迟服务的实例化。Lazy<T>会在你第一次访问Value属性时才触发容器创建服务实例，这样当你调用Method2/3时，IServiceA不会被初始化：

public class MyClass
{
    private readonly Lazy<IServiceA> _lazyServiceA;
    private readonly IServiceB _serviceB;

    // 注入Lazy<IServiceA>替代直接注入IServiceA
    public MyClass(Lazy<IServiceA> lazyServiceA, IServiceB serviceB)
    {
        _lazyServiceA = lazyServiceA;
        _serviceB = serviceB;
    }

    public void Method1()
    {
        // 只有这里调用时，IServiceA才会被实例化
        _lazyServiceA.Value.ExecuteOperation();
    }

    public void Method2()
    {
        _serviceB.DoTaskX();
    }

    public void Method3()
    {
        _serviceB.DoTaskY();
    }
}

优点：

• 改动最小，不需要调整类的结构，只需要修改构造函数的注入类型
• Unity原生支持，不需要额外配置
• 明确控制了服务实例化的时机

缺点：

• 类依然承担了多个职责，长期来看可能还是会变得难以维护
• 如果你不小心在其他方法里访问了_lazyServiceA.Value，还是会触发实例化

3. 属性注入（谨慎使用） #

Unity支持属性注入，你可以把非必要的依赖改成属性注入，标记[Dependency]特性。这样容器不会在构造函数阶段实例化该服务，只有当你访问这个属性时才会创建实例：

public class MyClass
{
    // 属性注入，仅在首次访问时实例化
    [Dependency]
    public IServiceA ServiceA { get; set; }

    private readonly IServiceB _serviceB;

    // 构造函数只注入必要的IServiceB
    public MyClass(IServiceB serviceB)
    {
        _serviceB = serviceB;
    }

    public void Method1()
    {
        ServiceA.ExecuteOperation();
    }

    public void Method2()
    {
        _serviceB.DoTaskX();
    }
}

优点：

• 构造函数只保留必要的依赖，避免了不必要的实例化
• 改动量较小

缺点：

• 依赖关系变得不明显，从构造函数无法看出类需要IServiceA
• 存在空引用风险：如果容器没有注入ServiceA，调用Method1时会抛出NullReferenceException
• 不符合“构造函数注入强制依赖，属性注入可选依赖”的最佳实践，所以只适合IServiceA是可选依赖的场景

4. 工厂模式 #

如果需要更精细地控制服务的创建时机（比如需要多次创建实例），可以引入工厂类，通过工厂来获取服务，而不是直接注入：

// 定义工厂接口
public interface IServiceFactory
{
    IServiceA CreateServiceA();
}

// 实现工厂，依赖Unity容器来创建服务
public class UnityServiceFactory : IServiceFactory
{
    private readonly IUnityContainer _container;

    public UnityServiceFactory(IUnityContainer container)
    {
        _container = container;
    }

    public IServiceA CreateServiceA()
    {
        return _container.Resolve<IServiceA>();
    }
}

// 修改你的类，注入工厂而不是直接注入IServiceA
public class MyClass
{
    private readonly IServiceFactory _serviceFactory;
    private readonly IServiceB _serviceB;

    public MyClass(IServiceFactory serviceFactory, IServiceB serviceB)
    {
        _serviceFactory = serviceFactory;
        _serviceB = serviceB;
    }

    public void Method1()
    {
        // 调用Method1时才通过工厂创建IServiceA实例
        var serviceA = _serviceFactory.CreateServiceA();
        serviceA.ExecuteOperation();
    }

    public void Method2()
    {
        _serviceB.DoTaskX();
    }
}

优点：

• 完全控制服务的创建时机和方式
• 适合需要创建多个实例或者需要传入参数创建实例的场景

缺点：

• 增加了额外的工厂类和接口，代码复杂度有所提升
• 类依赖于工厂，而不是直接依赖服务，稍微违反了依赖反转原则（不过工厂本身也是抽象的，影响不大）

总的来说，优先考虑拆分类，这是最符合设计原则的方案；如果暂时不想重构，延迟注入是最简单有效的替代方案；属性注入和工厂模式则根据具体场景选择使用。

内容的提问来源于stack exchange，提问作者rahulaga-msft