问什么时候使用依赖注入模式不合适？

EN

基本上，依赖注入对对象的性质做出了一些(通常但并非总是有效的)假设。如果这些都是错误的，DI可能不是最好的解决方案：

• 首先，基本上，DI假设对象实现的紧密耦合总是不好的。这就是依赖倒置原则的本质：“依赖不应建立在具体的基础上，而只应建立在抽象上”。这将关闭依赖对象以根据对具体实现的更改进行更改；如果输出需要转到文件中，则依赖于ConsoleWriter的类将需要更改，但是如果类仅依赖于一个IWriter，则可以用FileWriter替换当前使用的ConsoleWriter，并且我们的依赖类将不知道两者的区别(Liskhov替换原则)。但是，设计绝不能对所有类型的更改关闭；如果IWriter接口本身的设计发生变化，为了添加要写入()的参数，必须在实现对象/方法及其用法(S)之上更改额外的代码对象( IWriter接口)。如果实际接口中的更改比对所述接口的实现的更改更有可能发生，则松散耦合(以及依赖松散耦合的DI-ing )可能会导致比它解决的更多的问题。
• 第二，也是推论，DI假设依赖类从来不是创建依赖关系的好地方。这就是单一责任原则；如果您有创建依赖项并同时使用它的代码，那么依赖类可能必须更改两个原因(更改使用或实现)，这违反了SRP。但是，为DI添加层间接性可能是一个不存在的问题的解决方案；如果将逻辑封装到依赖项中是合乎逻辑的，但该逻辑是依赖关系的唯一此类实现，那么编写依赖关系的松散耦合解决方案(注入、服务位置、工厂)要比仅仅使用new而忘记它要痛苦得多。
• 最后，DI本质上集中了所有依赖项及其实现的知识。这增加了执行注入的程序集必须具有的引用数，而且在大多数情况下不会减少实际依赖类程序集所需的引用数。在某个地方，为了“连接点”并满足这种依赖关系，必须了解依赖关系、依赖接口和依赖关系实现。DI倾向于将所有这些知识放在一个非常高的级别上，要么放在IoC容器中，要么放在创建“主”对象的代码中，比如主窗体或控制器，这些对象必须水合物(或为依赖提供工厂方法)。这可以在应用程序的高级别上放置大量必要的紧密耦合的代码和大量的程序集引用，而应用程序只需要这些知识来“隐藏”实际的依赖类(从非常基本的角度来看，这些类是拥有这些知识的最佳地方；它是使用的地方)。它通常也不会从代码的较低处删除上述引用；依赖方仍然必须引用包含其依赖项的接口的库，该库位于以下三个位置之一：
  • 所有的程序集都是以应用为中心的“接口”程序集，
  • 在主实现(S)旁边的每个实现，消除了在依赖关系更改时不必重新编译受抚养人的优点，或者
  • 在高度内聚的程序集中，每个程序集中有一两个，这会使程序集数量增加，大大增加“完整构建”次数，并降低应用程序性能。

所有这些，再一次解决一个可能没有问题的地方。

在依赖注入框架之外，依赖注入(通过构造函数注入或setter注入)几乎是一个零和游戏:您减少了对象A与其依赖项B之间的耦合，但现在任何需要A实例的对象现在也必须构造对象B。

您已经稍微减少了A和B之间的耦合，但是减少了A的封装，增加了A和任何必须构造A实例的类之间的耦合，方法是将它们耦合到A的依赖项。

因此，依赖注入(没有框架)同样有害，因为它是有用的。

然而，额外的成本通常是合理的:如果客户端代码比对象本身更了解如何构造依赖项，那么依赖注入确实减少了耦合；例如，Scanner不知道如何获得或构造要解析输入的输入流，或者客户端代码希望解析输入的源，因此构造函数注入输入流是显而易见的解决方案。

为了能够使用模拟依赖项，测试是另一个理由。这应该意味着添加一个只用于测试的额外构造函数，该构造函数允许注入依赖关系:如果您将构造函数更改为总是要求注入依赖项，那么突然之间，您必须了解依赖项的依赖项，才能构造直接依赖关系，并且无法完成任何工作。

这可能很有帮助，但是您应该明确地问自己每个依赖项，测试的好处值得花费吗?我真的想在测试时模拟这种依赖吗？

当添加依赖注入框架，并且依赖关系的构造不是委托给客户端代码，而是委托给框架时，成本/效益分析就会发生很大的变化。

在依赖注入框架中，权衡有一点不同；注入依赖关系所失去的是，您能够轻松地知道您所依赖的实现，并将决定您所依赖的依赖项的责任转移到某些自动解决过程(例如，如果我们需要一个@ injecting‘’ed，必须有某种东西“提供Foo，其注入的依赖项是可用的)”，或者是一些高级配置文件，该文件规定了每个资源应该使用什么提供程序，或者是这两者的某个混合体(例如，对于依赖项可能会有一个自动解决过程，如果必要的话，可以使用配置文件)。

在构造函数注入中，我认为这样做的好处同样与这样做的成本非常相似:您不需要知道是谁提供了您所依赖的数据，如果有多个潜在的提供程序，您不需要知道首选的检入提供程序的顺序，确保每个需要对所有潜在提供者进行数据检查的位置，等等，因为所有这些都是由依赖注入平台在较高级别上处理的。

虽然我个人对DI框架没有太多的经验，但我的印象是，当查找您需要的数据或服务的正确提供者时，当您需要的数据或服务的正确提供者遇到麻烦时，当某些事情失败时，无法立即知道本地是什么代码提供了错误的数据，导致您的代码出现故障时，它们带来的好处大于成本。

在某些情况下，在DI框架出现时，已经采用了一些模糊依赖关系的模式(例如服务定位器)(也许也证明了它们的价值)，而采用DI框架是因为它们提供了一些竞争优势，例如需要更少的样板代码，或者在需要确定实际使用的提供者时，更少地掩盖依赖关系的提供者。

1. 如果要创建数据库实体，则应该有一些工厂类，然后将其插入到控制器中，
2. 如果您需要创建像int或long这样的原始对象。此外，您应该创建“手动”大多数标准库对象，如日期、guids等。
3. 如果您想注入配置字符串，最好是注入一些配置对象(通常，建议将简单类型封装到有意义的对象中: int temperatureInCelsiusDegrees -> CelciusDeegree CelciusDeegree)

不要使用服务定位器作为依赖注入替代，它是反模式的，更多信息：http://blog.ploeh.dk/2010/02/03/ServiceLocatorIsAnAntiPattern.aspx