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

Question

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

Answer 1

我真的很喜欢这篇关于 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?”

这篇文章是为后者的人写的——它并不意味着详尽，但希望它也不是完全没有帮助:-)

Answer 2

In my opinion, Dhanji Prasanna's book Dependency Injection is a must read for software designers, both beginners and experts. It deals directly with your DI questions.

Answer 3

Guice 的用户指南中有一个最佳实践部分。

Answer 4

我发现当我看到违反Demeter 定律时，这暗示我可能需要依赖注入。

例如：

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

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

Answer 5

我关于何时使用 DI 的基本规则是我将在层之间注入，所以在我的控制器和 dao 之间将是一个层，所以我可以注入，这样如果我想模拟一个层，我可以。

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

例如，如果您的 DAO 可能位于不同的计算机上，那么您可能需要能够假装它们是一层，但使用 DI 在一台机器上的所有和单独的机器之间实际切换。然后开发人员可以在一台机器上做所有事情，它应该在不同的机器上工作。

但是，除非有迫切的需要，否则我认为同一层内的 DI 是不必要的复杂化。

Answer 6

这是一个依赖注入反模式：Multiple Constructors。