n层应用程序中的依赖注入？

Question

我有一个3层.NET服务的应用程序，它遵循的标准方法：

Frontend -> Object Model/Business Logic -> Data Access 

我想了解沿途依赖注入，因此到目前为止已经发现了它巨大的（使用Autofac） 。 3层中的每一层都需要创建各种对象，有时还需要额外的配置/等等。似乎DI容器应该是解决这个问题的理想工具，但是我有一些问题要看它应该与系统的其他部分相连。

目前我在配置DI容器的前端有一个类。它基本上是一大堆代码，说container.Register<SomeType>()等等。

问题是，它正在为所有3层配置容器，因此必须具有对数据访问层的相当侵入性的知识。在我的前台使用这些知识代码在我的脑海中引发了警钟，因为将应用程序分成多个层级的目的是为了避免这种情况。
由于我的数据访问层不仅仅是SQL服务器，而且是由大量复杂的COM互操作和P/Invoke调用组成的，因此这也会变得更糟。 DI配置。我已经给出了一些想法来打破它 - 也许每层有一个容器，或在每层中有一个“安装”类与全球DI容器进行对话以注册它自己的位，但我不确定如果这会导致更多的问题比它解决...

我真的很感激，如果任何人都可以分享他们的经验，使用DI多层应用程序。

谢谢，猎户座。

Answer 1

这取决于您是否有三层（物理分离）或者所有逻辑层都一起部署。如果前端与BL分离并通过Web服务或WCF通信，则前端和后端需要自己的容器，因为它们在单独的进程或单独的机器中运行。容器只会注册自己的组件和“下一个”层的接口。

另一方面，如果所有图层都在同一个进程中运行，那么您应该只有一个容器。该容器将被初始化并托管在应用程序的起始点，如用于Web应用程序的global.asax。

容器主机知道系统的所有不同部分的问题可以通过不逐一注册类来解决，而是在一个程序集中注册所有类型。这样你就不需要对解决方案中所有组件的强引用来配置容器。 Castle Winsdor如何做到这一点的例子：

Kernel.Register(AllTypes.Pick().FromAssemblyName("DataAccessLayer.dll")); 
Kernel.Register(AllTypes.Pick().FromAssemblyName("BusinessLogic.dll"));