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

Question

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

Answer 1

我非常喜欢这篇关于DI的文章，因为它针对的是没有大量DI体验的人，或者甚至不知道它是什么。

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

  

什么是Unity？

It’s a “dependency injection container”.

     

现在，在那一点上，一群人   读这会说“是的，我们知道   我们已经将它用于原因了   A，B，C或我们选择不使用它   由于原因X，Y，Z“我想象一个   一群其他人可能会说;

“Huh? What’s a dependency injection container?”

     

这篇文章适合后者 -   它并不意味着详尽无遗   希望它不完全   没有任何帮助： - ）

Answer 2

在我看来，Dhanji Prasanna的书Dependency Injection是软件设计师必读的内容，包括初学者和专家。它直接涉及您的DI问题。

Answer 3

Guice的user's guide中有一个最佳实践部分。

Answer 4

我发现，当我发现违反Law of Demeter时，我可能会想要依赖注入。

例如：

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

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

Answer 5

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

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

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

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

Answer 6

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