依赖注入最佳实践答案

【问题标题】：Dependency Injection Best Practices依赖注入最佳实践
【发布时间】：2010-12-11 05:13:16
【问题描述】：

我在我的代码中使用依赖注入（使用Ninject）并认为我做得很好，直到我遇到一个性能问题，这是由于对 DI 容器适合您的代码的位置的误解而引起的。似乎有很多关于如何使用 DI 框架的信息，但没有太多关于在哪里不使用它们或如何最好地使用它们的信息（至少我能找到）

我想我会写出我认为的一些最佳做法，看看其他人是否同意我的观点，以及人们能提出哪些其他最佳做法。

【问题讨论】：

【解决方案1】：

以下是最重要点的简短列表（其中一些也出现在 OP 中）：

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

【讨论】：

嗨，Mark，请参阅此处 (groups.google.com/group/ninject/browse_thread/thread/…) 关于 Ninject 在应用程序中的性能的讨论。像你一样，我认为 DI 容器应该在任何地方使用，但是 DI 容器的开销使得创建大量瞬态对象可能会很突兀。您的建议可能对 Web 应用程序非常有用，但在其他领域则不然。
我浏览了那个讨论，但我认为我同意 Nate 的观点。应该使用 DI 来解决和注入依赖关系，但是如果通过 DI 容器创建数十万个对象，那么整体设计就会出现问题。这绝不是 DI 的意图。我本可以在我的列表中添加另一个要点：“Voror decoupling Volatile Dependencies over Stable Dependencies”，但这更像是一般的设计建议，而不是特定的 DI 事物。
我同意瞬态对象 - 大多数使用 DI 的应用程序会创建大量瞬态对象。一些容器（Unity 和很快的 Autofac 2）默认为瞬态而不是 Singleton。我不认为“首选单例”可以被视为最佳实践——它似乎更像是对特定容器在特定场景中的性能的评论。

【解决方案2】：

仅对长寿命的单例对象使用 DI 容器，对短寿命的瞬态对象使用工厂（或其他方法）

但请务必使用 DI 将工厂注入到需要的地方。

【讨论】：