有一件事让我对DI有点不安，那就是假设所有注入的对象都很容易实例化，而且不会产生副作用- or -依赖关系被频繁使用，以至于它超过了任何相关的实例化成本。

当依赖项在消费类中不经常使用时，这一点可能很重要;比如IExceptionLogHandlerService。显然，这样的服务很少在类中调用(希望:))——大概只在需要记录异常时调用;然而，规范的构造器-注入模式……

Public Class MyClass
    Private ReadOnly mExLogHandlerService As IExceptionLogHandlerService

    Public Sub New(exLogHandlerService As IExceptionLogHandlerService)
        Me.mExLogHandlerService = exLogHandlerService
    End Sub

    ' ...
End Class

.．.要求提供该服务的“活动”实例，该死的成本/副作用。并不是说它可能会这样做，但是如果构建这个依赖实例涉及到服务/数据库命中，或配置文件查找，或在释放之前锁定资源，该怎么办呢?如果该服务是按需构建的、服务定位的或工厂生成的(它们都有各自的问题)，那么您将只在必要时才承担构建成本。

Now, it is a generally accepted software design principle that constructing an object is cheap and doesn't produce side-effects. And while that's a nice notion, it isn't always the case. Using typical constructor-injection however basically demands that this is the case. Meaning when you create an implementation of a dependency, you have to design it with DI in mind. Maybe you would have made object-construction more costly to obtain benefits elsewhere, but if this implementation is going to be injected, it will likely force you to reconsider that design.

顺便说一下，某些技术可以通过允许延迟加载注入的依赖项来缓解这个问题，例如，提供一个Lazy<IService>实例类作为依赖项。这将改变依赖对象的构造函数，并使其更加了解实现细节，例如对象构造开销，这也可以说是不可取的。

它可以增加应用启动时间，因为IoC容器应该以适当的方式解析依赖关系，有时需要进行多次迭代。

我发现构造函数注入会导致构造函数又大又丑(我在整个代码库中都使用它——也许我的对象太细了?)此外，有时使用构造函数注入会导致可怕的循环依赖(尽管这种情况非常罕见)，因此您可能会发现自己必须在更复杂的系统中拥有某种就绪状态生命周期，并进行几轮依赖注入。

然而，我更喜欢构造器注入而不是setter注入，因为一旦我的对象被构造，那么我就可以毫无疑问地知道它处于什么状态，它是在单元测试环境中还是加载到某个IOC容器中。这，以一种迂回的方式说，我觉得是setter注入的主要缺点。

(作为旁注，我确实发现整个主题相当“宗教”，但你的成就将随着开发团队的技术狂热程度而变化!)

基于构造函数的依赖注入(没有神奇的“框架”的帮助)是构造OO代码的一种干净而有益的方式。在我所见过的最好的代码库中，经过多年与Martin Fowler的其他前同事的相处，我开始注意到大多数以这种方式编写的优秀类最终都只有一个doSomething方法。

那么，主要的缺点是，一旦您意识到这只是一种笨拙的、冗长的OO方式，将闭包编写为类，以获得函数式编程的好处，那么您编写OO代码的动机就会迅速消失。

依赖注入是一种技术或模式，与任何框架无关。您可以手动连接依赖项。DI帮助您实现SR(单一职责)和SoC(关注点分离)。DI会带来更好的设计。从我的观点和经验来看，没有坏处。就像任何其他模式一样，你可能会弄错或误用它(但在DI的情况下很难)。

如果您使用框架将DI作为原则引入到遗留应用程序中，那么您可能犯的最大错误就是将其误用为服务定位器。DI+框架本身是伟大的，只是让事情变得更好，我看到它!从组织的角度来看，每一个新的过程、技术、模式……都有共同的问题:

你必须训练你的团队 您必须更改您的应用程序(这包括风险)

一般来说，你必须投入时间和金钱，除此之外，没有任何负面影响，真的!

我不认为存在这样的列表，但是试着阅读这些文章:

DI会模糊代码(如果你没有使用好的IDE) Bob叔叔认为，误用IoC会导致糟糕的代码。 需要注意过度设计和创造不必要的多功能性。