我的应用程序将包含以下组件：
我希望使用Castle Windsor作为IoC来将这些层粘合在一起，但我对粘合的设计有些不确定。
我的问题是谁应该负责将对象注册到Windsor中？ 我有几个想法：
我正在寻求一些不同路径的想法和优缺点。
通常情况下，应用程序中的所有组件都应该尽可能晚地进行组合，这可以确保最大化模块化，并使模块之间的耦合尽量松散。
实际上，这意味着您应该在应用程序的根处配置容器。
容器只是将模块组合成工作应用程序的引擎。原则上，您可以手动编写代码（这称为“贫民版 DI”），但使用像 Windsor 这样的 DI 容器会更加轻松。
这样的 组合根 理想情况下应该是应用程序根中唯一的代码片段，使应用程序成为所谓的 Humble Executable（来自优秀的 xUnit Test Patterns 一书）。这样的应用程序本身不需要单元测试。
您的测试不应该需要容器，因为您的对象和模块应该是可组合的，并且您可以直接从单元测试中向它们提供 Test Doubles。最好设计所有模块都不依赖于容器。
此外，在 Windsor 中，您应该在安装程序（实现 IWindsorInstaller 接口的类型）中封装组件注册逻辑。有关更多详细信息，请参见文档。
1）依赖容器持有应用程序中许多组件的引用。将此“坏男孩”传递给需要创建/管理另一个子组件的每个组件，相当于在您的架构中使用全局变量。更糟糕的是，任何子组件也可以向容器注册新组件，因此很快它也将成为全局存储。开发人员将对象放入容器中，只是为了在组件之间传递数据（无论是在兄弟控制器之间还是在深层控制器层次结构之间 - 即：祖先控制器需要从祖父控制器获取数据）。请注意，在Web世界中，容器不会传递给用户代码，因此这永远不是问题。
2) 依赖容器与服务定位器/工厂/直接对象实例化相比的另一个问题是，从容器中解析使得无法确定您是正在创建组件还是仅重用现有组件。相反，由一个集中的配置(即:引导程序/组合根)来确定组件的生命周期。在某些情况下，这是可以接受的(例如: web控制器，在这种情况下，需要管理组件生命周期的不是用户代码，而是运行时请求处理框架本身)。然而，当您的组件的设计应指示它们是否负责管理组件以及其生命周期应该是什么时，这就变得非常棘手(例如:电话应用程序弹出一个要求用户输入一些信息的视图控制器。这通过控制器创建一个子控制器来实现，该子控制器管理覆盖视图。一旦用户输入了一些信息，表格被撤消，并将控制权返回给最初的控制器，该控制器仍保持先前用户所做的状态)。如果使用DI解析表格子控制器，则无法确定其生命周期或者谁应该负责管理它(发起控制器)。与其他机制的明确责任相比较。场景A:
// not sure whether I'm responsible for creating the thing or not
DependencyContainer.GimmeA<Thing>()
// responsibility is clear that this component is responsible for creation
Factory.CreateMeA<Thing>()
// or simply
new Thing()
方案 C：
// responsibility is clear that this component is not responsible for creation, but rather only consumption
ServiceLocator.GetMeTheExisting<Thing>()
// or simply
ServiceLocator.Thing
那测试性呢？
“即使没有依赖注入框架，也完全可以实现可测试性。” 我建议使用拦截框架，例如 UnitBox（免费）或TypeMock（价格较高）。这些框架提供了您需要解决问题的工具（如何在 C# 中模拟实例化和静态调用），并且不需要更改整个架构以解决它们（不幸的是，在 .NET/Java 世界中，这已经成为趋势）。更明智的做法是找到解决问题的方法，并使用最适合底层组件的自然语言机制和模式，而不是试图把每个方形钉子塞进圆形依赖注入孔中。一旦您开始使用这些更简单、更具体的机制，您会发现如果有的话，您的代码库中几乎不需要使用依赖注入。"