我在依赖注入方面相对不熟练,我想学习一些在使用 DI 时分别使用和避免的最佳实践和反模式。
6 回答
我真的很喜欢这篇关于 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?”
这篇文章是为后者的人写的——它并不意味着详尽,但希望它也不是完全没有帮助:-)
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.
Guice 的用户指南中有一个最佳实践部分。
我发现当我看到违反Demeter 定律时,这暗示我可能需要依赖注入。
例如:
void doit()
{
i += object.anotherobject.addvalue; //violation of Law of Demeter
}
有时暗示我可能想要依赖注入anotherobject
。
我关于何时使用 DI 的基本规则是我将在层之间注入,所以在我的控制器和 dao 之间将是一个层,所以我可以注入,这样如果我想模拟一个层,我可以。
我认为在同一层中使用 DI 并不是一个好主意,主要是因为该层应该紧密耦合,因为它们是相关的,除非您有一个有用的用户故事。
例如,如果您的 DAO 可能位于不同的计算机上,那么您可能需要能够假装它们是一层,但使用 DI 在一台机器上的所有和单独的机器之间实际切换。然后开发人员可以在一台机器上做所有事情,它应该在不同的机器上工作。
但是,除非有迫切的需要,否则我认为同一层内的 DI 是不必要的复杂化。
这是一个依赖注入反模式:Multiple Constructors。