依赖注入最佳实践

我在我的代码中使用依赖注入（与Ninject），并认为我做得相当不错，直到遇到由于误解DI容器适合代码的位置而导致的性能问题。似乎有很多关于如何使用DI框架的信息，但没有太多关于不使用它们的地方或如何最好地使用它们（至少我能找到）依赖注入最佳实践

我想我会写出我想到的是一些最佳实践，并看看其他人是否同意我的观点以及人们可以提出哪些其他最佳实践。每个应用程序或应用程序域

使用一个内核
使用长寿命辛格尔顿的DI容器对象只，使用工厂（或其他方式）进行短暂的临时对象）
青睐构造方法注入了物业或现场注入
请求对象，不建立它们
其他??指向好的博客条目/文章？

来源

2009-10-29 Jeffrey Cameron

什么是内核？是一个Ninject特定的概念（在其他地方还没有见过）？ – zvolkov 2009-11-03 02:08:45

此外，二传手与构造器注射是一种宗教论点，因此应该避免。 – zvolkov 2009-11-03 02:11:54

这里是最重要的点的名单（其中一些也出现在OP）：

代码应该是不知道哪些DI容器（如果有的话）用于
撰写在应用程序的根整个应用程序（构图根）
青睐构造器注入

我不能说，我同意你的观点关于Singleton与瞬态对象。 DI的重点在于外部机制（如DI容器）决定任何给定依赖关系的生命周期，而不是其他人，因此您需要拥有DI容器管理的所有依赖关系。

来源

2009-10-29 11:48:00

Hi Mark，请参阅此处的讨论（http://groups.google.com/group/ninject/browse_thread/thread/41ec03527da9f0f8），了解Ninject在应用程序中的性能。和你一样，我认为应该在任何地方都使用DI容器，但DI容器的开销是这样的，即创建大量的瞬态对象可能是突兀的。您的建议对于Web应用程序来说可能很好，但对其他领域来说则不是那么重要 – 2009-10-29 17:57:55

我撇开了这个讨论，但我想我赞同Nate那里。应该使用DI来解决和注入依赖关系，但是如果通过DI容器创建数十万个对象，那么总体设计会出现问题。这绝不是DI的意图。我可以在列表中添加另一个项目符号：“支持将稳定依赖关系中的易失性依赖关系解耦”，但这更像是一个通用设计建议，而不是特定的DI事务。 – 2009-10-29 19:54:21

我同意关于瞬态对象 - 大多数使用DI的应用程序会创建大量的瞬态对象。一些容器（Unity和即将Autofac 2）默认为瞬态而不是Singleton。我不认为“更喜欢单身人士”可能被视为最佳实践 - 它似乎更像是对特定场景中特定容器性能的评论。 – 2009-10-30 04:38:03

使用DI容器长住辛格尔顿只对象，请使用工厂（或其他方式）进行短暂的临时对象）

但不要使用DI注入工厂到那里需要。

来源

2009-11-03 01:56:38 flukus

依赖注入最佳实践

回答

相关问题