相关疑难解决方法(0)

我正在尝试将DI作为一种模式在工作中引入,我们的一位主要开发人员想知道:什么 - 如果有的话 - 是使用依赖注入模式的缺点？

注意我在这里寻找 - 如果可能 - 详尽的清单,而不是关于该主题的主观讨论.

澄清:我在谈论依赖注入模式(参见Martin Fowler的这篇文章),而不是一个特定的框架,无论是基于XML(如Spring)还是基于代码(如Guice),还是"自我推销" .

编辑:这里有一些很好的进一步讨论/咆哮/辩论/ r /编程.

当谈到典型的构造函数依赖注入时,我很难理解看似明显的模式问题/限制.例如,假设我有一个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容器被要求实例化所有三个依赖项,这个控制器上的操作方法可能只需要一部分依赖项.

似乎假设对象构造是肮脏的,并且没有来自对象构造的副作用或者所有依赖性都被一致地利用.如果物体结构没有吱吱声或有副作用怎么办？例如,如果构建 …