依赖注入最佳实践和反模式

我在依赖注入方面相对不熟练，我想在使用DI时分别学习一些最佳实践和反模式以避免使用和避免。依赖注入最佳实践和反模式

2009-11-05 ripper234

我不认为“语言无关”在这里帮助：不同的语言决定完全不同的方式 - 你真的不想做同样的事情在C++的，说的红宝石。 – 2009-11-05 19:36:00

那么，为每种语言提出单独的问题可能是值得的？尽管如此，我想有足够的通用模式，所以通用的问题是有序的。 – ripper234 2009-11-05 21:19:53

我鼓励任何有兴趣参与这个问题的人去查看[依赖注入文档]（http://stackoverflow.com/documentation/dependency-injection/topics）主题。 – dimo414 2017-02-08 00:37:58

我发现，当我看到Law of Demeter的违规是，我可能要依赖注入的提示。

例如：

void doit() 
{ 
    i += object.anotherobject.addvalue; //violation of Law of Demeter 
}

有时暗示我可能要依赖注入anotherobject。

来源

2009-11-05 18:33:51

似乎有点任意... – 2009-11-05 19:49:15

这虽然有点意义，但是不完整。如果你发现违反德米特法则，你会找到一个选择抽象的机会。无论何时你抽象，你都有机会选择注入依赖而不是自己创建它。所以这是一个指标，但只是。可能有更多的机会进行抽象而不仅仅是这一点，并且在实施成本更高的地方避免DI可能是有用的，而不是可能从中解脱出来。尽管如此，+1。 – 2011-05-02 09:59:26

关于什么时候使用DI的基本规则是我会在层之间注入，所以在我的控制器和dao之间会是一个图层，所以我可以注入，所以如果我想模拟一个图层我就可以。

我认为在同一层中使用DI是不是一个好主意，主要是因为该层应紧密耦合，因为它们是相关的，除非你有一个用户故事，使得它非常有用。

例如，如果你的DAO是可以在单独的计算机上，那么你可能需要能够假装他们是一层，但使用DI一体机不同的机器上的所有之间的实际切换。然后开发人员可以在一台机器上完成所有工作，并且可以在单独的机器上工作

但是，除非有一些迫切的需要，我认为在同一层内的DI是不必要的并发症。

来源

2009-11-05 18:40:04

在图层中使用依赖注入，您将重新使用现有组件实例，节约资源。另外，我会说你通过强制模块化设计来培养良好的编程习惯。 – 2009-11-05 21:29:58

我只是看到它变得比它需要更复杂，但这取决于图层上的内容。我倾向于在图层之间做这件事，但这就是为什么我解释了为什么在图层之间做它会有所帮助，而不是我会建议的。 – 2009-11-05 21:37:40

在我看来，Dhanji人员Prasanna的书Dependency Injection是一个必须阅读软件设计，初学者和专家。它直接处理你的DI问题。

来源

2009-11-05 19:13:57 jnorris

另一本很棒的书是[来自Mark Seemann的.NET中的依赖注入]（http://www.amazon.com/Dependency-Injection-NET-Mark-Seemann/dp/1935182501）。 – Steven 2013-07-02 08:04:31

我真的很喜欢这篇文章关于DI，因为它面向的是谁没有一吨的DI经验，或者甚至不知道它是什么的人。

https://mtaulty.com/2009/08/10/m_11554/

什么是团结？现在
It’s a “dependency injection container”. 
，在这一点上一堆人阅读这个会说：“是的，我们知道并且我们已经在使用它的原因 A，B，C或我们选择不使用它原因X，Y，Z“ ”我想象一个其他人可能会说;
“Huh? What’s a dependency injection container?” 
这篇文章是后者的人 - 它并不意味着是详尽的，但希望这不是一个完全无用要么:-)

来源

2009-11-05 19:39:02