使用服务层时，配置IoC容器的正确层是什么？

Question

我有一个中等大小的asp.net MVC应用程序。它使用一个服务层来处理所有的存储库使用，调用域服务等。我的控制器操作非常小 - 它们基本上调用服务类，获得响应并显示respose。大多数组件都是基于界面的一些穷人的DI。该应用程序正在增长，需要更好的测试支持，并开始呼叫IoC容器。

我读到的所有内容（例如this SO question）都声明我应该在应用程序根目录配置IoC。如果我从控制器操作中使用存储库并且在控制器级别需要DI，这对我来说是有意义的，但我不是。好像我希望我的作品根在我的服务层中。我一直认为我不希望我的web.config（或其他配置）在UI层甚至提及/看到/听到有关存储库，信用卡处理器等。

我是否正确地思考这个问题，还是只需要克服它？

Answer 1

我和你的情况相同，我按照以下方式处理。

我使用的一般规则是具有global.asax或类似的东西，它需要执行注册IoC组件的代码。另一种方法是，你需要为每个正在运行的不同进程运行一个（即网站在一个进程中，而服务在另一个进程中）。

在我的情况下，我为mvc网站global.asax和服务器再次执行此操作。在这种情况下，服务和网站之间的注册会有所不同。

另外我还做了一件事。由于我在mvc应用程序和服务之间重用组件（即日志记录），我有第三个核心组件，用于注册系统的核心IoC组件，并且该组件由网站和服务注册调用。因此，我在服务和网站之间的任何共同点进入核心注册，然后任何不同的东西进入“界面”特定注册。

希望有所帮助。

Answer 2

你只需要克服它：）

在应用程序根目录中使用 Composition Root 并不需要在web.config中包含大量DI Container内容。你可以，但它是可选的。将组合根放入应用程序根目录时，不可选是什么，需要在Global.asax中包含一些DI代码。

您可能会发现它无关紧要，因为您的控制器非常薄，但这不是真正的重点。实际的一点是，你（摘要'你'）想要推迟耦合类，直到最后一个负责时刻。你加入类型越早，你的灵活性就越低。

如果您在服务层中结合了类，那么您就可以做出不可逆转的决定。如果后来证明你需要以不同的方式组合这些服务，你就不能 - 不是没有重新编译，就是这样。

如果这样做有一个重大好处，我可以理解你想要的原因，但事实并非如此。您也可以等待组成所有组件，直到您绝对必须这样做 - 这就是应用程序的入口点。

Answer 3

从Java的角度来看，我将Spring框架用于我的IoC容器。有了它，容器确实是应用程序范围的。虽然您可以为不同的层（持久性配置文件，服务配置文件，控制器配置文件等）提供不同的配置文件，但所有对象（Java术语中的bean）都会进入容器。

我认为这仍然可以，因为你提到的类之间没有耦合。视图不需要知道信用卡处理器，只是因为它们位于同一个IoC容器中。这些类将仅（通过注入）接收它们所需的依赖项，并且不关心容器中的其他对象。