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

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

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

我一直在努力学习依赖注入，到目前为止，我发现它非常棒（使用Autofac）。3层中的每一层都需要创建一系列的对象，有时还需要额外的配置/等等。看起来DI容器应该是解决这个问题的理想选择，但是我在了解它与系统其余部分的关系时遇到了一些问题

目前，我在前端有一个类，用于配置DI容器。它基本上是一大堆代码，比如说

container.Register（）

等等

问题是，它正在为所有3层配置容器，因此必须对数据访问层有相当深入的了解。在我的前端使用具有此类知识的代码会在我的头脑中敲响警钟，因为将应用程序划分为多个层次的目的是为了避免这种情况。
更糟糕的是，我的数据访问层不仅仅是SQL server，它是由大量复杂的COM互操作和P/Invoke调用组成的，因此对DI配置有很大的影响

我已经考虑过将其分解——也许每层有一个容器，或者每层都有一个“Setup”类与全局DI容器通信以注册它自己的位，但我不确定这是否会导致比它解决的问题更多的问题

如果有人能分享他们在多层应用程序中使用DI的经验，我将不胜感激

---

谢谢，Orion。

这取决于您是否有三层（物理分离）或是否将所有逻辑层部署在一起。如果前端与BL分开，并通过webservice或WCF进行通信，那么前端和后端需要它们自己的容器，因为它们运行在不同的进程或机器中。容器将只注册自己的组件和“下一层”的接口

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

容器主机知道系统的大部分不同部分的问题可以通过不逐个注册类，而是注册程序集中的所有类型来解决。这样，您就不需要仅为了配置容器而对解决方案中的所有程序集进行强引用。使用Castle Winsdor可以实现这一点的示例：

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

---

您有类似于服务层的东西吗？因此，您的前端在业务对象之前与it进行交互。我不确定我是否理解您所说的“服务层”。。。如今，“服务”是一个被滥用的通用术语：-(