【.Net依赖注入】DI 合成根（Composition Root）

英文原文：

https://blog.ploeh.dk/2011/07/28/CompositionRoot/

 在我的书（Dependency Injection in .NET）中，我描述了第3章中的根构图模式(Composition Root pattern)。这篇文章是对该模式的总结描述。
 在出现后续问题之前，构造器注入模式是很容易理解的：

我们应该在哪里组成对象图？

 每个类都应该通过其构造函数要求其依赖项，这很容易理解，但这将组合类及其依赖项的责任推给了第三方。那应该在哪里呢？
在我看来，大多数人都渴望尽早组合，但正确答案是：

尽可能靠近应用程序的入口点。

此位置称为应用程序的合成根，定义如下：

合成根是(优选的)应用程序中模块被组合在一起的唯一位置。

 这意味着所有应用程序代码都完全依赖于构造函数注入(或其他注入模式)，但从不组合。只有在应用程序的入口点，才最终组成整个对象图。
适当的入口点取决于框架：

• 在控制台应用程序中，它是Main方法
• 在ASP.NET MVC应用程序中，它是global.asax和一个自定义IControllerFactory
• 在WPF应用程序中，它是Application.OnStartup方法
• 在WCF中，它是一个自定义的ServiceHostFactory
• 等等

(您可以在我的书的第7章中阅读有关特定于框架的合成根的更多信息。)
合成根是一个应用程序基础结构组件。

只有应用程序才应该有合成根。库和框架不应该。

Composal Root可以使用Poor Man‘s DI Pure DI实现，但也是(唯一)使用DI容器的合适位置。

DI容器只能从合成根引用。所有其他模块都不应该引用该容器。

使用DI容器通常是一个不错的选择。 在这种情况下，应该使用完全从合成根内部的注册解析释放模式来应用它。