DI 模式是否限制了昂贵的对象创建以及不频繁的依赖项使用？

Question

当涉及到典型的构造函数依赖注入时，我很难理解似乎明显的模式问题/限制。出于示例目的，假设我有一个 ASP.NET MVC3 控制器，如下所示：

Public Class MyController
    Inherits Controller

    Private ReadOnly mServiceA As IServiceA
    Private ReadOnly mServiceB As IServiceB
    Private ReadOnly mServiceC As IServiceC

    Public Sub New(serviceA As IServiceA, serviceB As IServiceB, serviceC As IServiceC)
        Me.mServiceA = serviceA
        Me.mServiceB = serviceB
        Me.mServiceC = serviceC
    End Sub

    Public Function ActionA() As ActionResult
        ' Do something with Me.mServiceA and Me.mServiceB
    End Function

    Public Function ActionB() As ActionResult
        ' Do something with Me.mServiceB and Me.mServiceC
    End Function
End Class

我很难克服的问题是 DI 容器被要求实例化所有三个依赖项在任何给定时间，该控制器上的操作方法可能只需要依赖项的子集。

似乎假设对象构造非常便宜，并且对象构造没有副作用，或者所有依赖项都得到一致利用。如果对象构造不便宜或者有副作用怎么办？例如，如果构造IServiceA涉及打开连接或分配其他重要资源，那么当调用ActionB时，这将完全浪费时间/资源。

如果这些操作方法使用服务位置模式（或其他类似模式），那么就永远不会有机会不必要地构造将不使用的对象实例，当然使用此模式会带来其他问题，使其没有吸引力。

使用 DI 的规范构造函数注入+接口模式是否基本上将开发人员锁定在某种“限制”中，即依赖项的实现必须很便宜才能实例化，或者必须充分利用实例？我知道所有模式都有其优点和缺点，这只是 DI 的缺点之一吗？我以前从未见过有人提到过它，我对此感到好奇。

Answer 1

如果您有很多字段并未被每个成员使用，则意味着该类的内聚力较低。这是一个通用的编程概念 - 构造函数注入只是让它更加明显。这通常是一个很好的指标，表明单一责任原则正在被违反。

如果是这种情况，请重构（例如Facade Services）。

创建对象图时不必担心性能。

当谈到副作用时，(DI) 构造函数应该简单并且没有副作用。

Answer 2

一般来说，对象构建不应该有重大成本或副作用。这是一个一般性的说法，我认为适用于大多数（不是全部）对象，但对于您通过 DI 注入的服务尤其如此。换句话说，构建服务类会自动进行数据库/服务调用，或者以产生副作用（至少是代码味道）的方式更改系统状态。

关于未使用的实例：无论您是否使用 DI，都很难创建一个能够完美利用依赖类中的实例的系统。我不确定实现这一点是否非常重要，只要您遵守单一责任原则。如果您发现您的类注入了太多服务，或者利用率确实不均匀，这可能表明您的类做得太多，需要分成两个或更多较小的类责任更加集中。

Answer 3

不，您不受所列出的限制的约束。从 .net 4 开始，您的计算机上确实有 Lazy(Of T)处置，这将允许您将依赖项的实例化推迟到需要时。

并不认为对象构造非常便宜，因此一些 DI 容器支持Lazy(Of T) 开箱即用。虽然 Unity 2.0 通过 支持开箱即用的延迟初始化自动化工厂，有一篇好文章此处支持 Lazy 的扩展（T） 作者在 MSDN。

Answer 4

你的控制器不是单例吗？这是在 Java 中执行此操作的正常方法。仅创建了一个实例。如果操作的角色如此不同，您还可以将控制器拆分为多个控制器。