我有一个3层的.NET服务应用程序，它遵循标准方法：
Frontend -> Object Model / Business Logic -> Data Access
我正在尝试沿途学习依赖注入，到目前为止已经发现它很棒（使用Autofac）。 3层中的每一层都需要创建各种各样的对象，有时需要额外的配置/等。似乎DI容器应该是解决这个问题的理想选择，但是我遇到了一些问题，看看它应该与系统的其他部分相关。
目前我在前端有一个配置DI容器的类。它基本上是一大串代码container.Register<SomeType>()等等。
问题是，它正在为所有3层配置容器，因此必须具有对数据访问层的相当侵入性的知识。在我的前端有这样的知识的代码在我的头脑中引起警钟，因为将应用程序分成层级的关键是避免这种情况。
由于我的数据访问层不只是SQL服务器是一个笨拙的桶，而是由许多复杂的COM互操作和P / Invoke调用组成，所以这也变得更糟，因此对DI有相当大的影响配置。
我已经考虑过将其分解 - 可能每层有一个容器，或者每层都有一个“Setup”类，它与全局DI容器对话以注册它自己的位，但我不确定是否这将导致比解决更多的问题......
如果有人可以分享使用DI与多层应用程序的经验，我将非常感激。
谢谢，猎户座。
答案 0 :(得分：3)
这取决于您是否有三层（物理分离）或所有逻辑层是否一起部署。如果前端与BL分开并通过Web服务或WCF进行通信，那么前端和后端需要自己的容器，因为它们在不同的进程或单独的机器上运行。容器只会注册自己的组件和“下一个”层的接口。
另一方面，如果所有图层都在同一个进程中运行，那么您应该只有一个容器。容器将初始化并托管在应用程序的起始点，如web应用程序的global.asax。
容器主机知道系统的所有不同部分的问题可以通过不逐个注册类来解决，而是在程序集中注册所有类型。这样，只需配置容器，就不需要对解决方案中的所有程序集进行强引用。使用Castle Winsdor可以完成的示例：
Kernel.Register(AllTypes.Pick().FromAssemblyName("DataAccessLayer.dll"));
Kernel.Register(AllTypes.Pick().FromAssemblyName("BusinessLogic.dll"));