7

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

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

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

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

问题是，它正在为所有 3 层配置容器，因此必须对数据访问层有相当深入的了解。在我的前端拥有这样知识的代码会在我脑海中敲响警钟，因为将应用程序分成几层是为了避免这种确切的情况。
更糟糕的是，我的数据访问层不仅仅是 SQL 服务器，它是一个愚蠢的比特桶，而是由许多复杂的 COM 互操作和 P/Invoke 调用组成，因此对 DI 有相当大的影响配置。

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

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

谢谢，猎户座。

4

1 回答 1

3

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

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

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

Kernel.Register(AllTypes.Pick().FromAssemblyName("DataAccessLayer.dll"));
Kernel.Register(AllTypes.Pick().FromAssemblyName("BusinessLogic.dll"));
于 2009-02-11T19:23:07.273 回答