asp.net-mvc-3 - DI 模式是否限制了昂贵的对象创建以及不经常使用的依赖项？

Question

当涉及到典型的构造函数依赖注入(inject)时，我很难理解似乎是一个明显的模式问题/限制。例如，假设我有一个 ASP.NET MVC3 Controller ，它看起来像:

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 容器被要求实例化所有三个依赖项，而在任何给定时间，此 Controller 上的操作方法可能只需要依赖项的一个子集。

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

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

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

Answer 1

如果你有很多字段没有被每个成员使用，这意味着类'凝聚力低 .这是一个通用的编程概念 - 构造函数注入(inject)只是让它更明显 . Single Responsibility Principle 通常是一个很好的指标。正在被侵犯。

如果是这种情况，那么重构(例如到 Facade Services )。

You don't have to worry about performance when creating object graphs .

说到副作用，(DI) constructors should be simple and not have side effects .