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

Question

我有一个中等大小的asp.net MVC应用程序，它消耗了一个处理所有存储库使用、调用域服务等的服务层。我的控制器操作非常简单 - 它们基本上调用一个服务类，获取一个响应并显示该响应。大多数组件都是基于接口的，具有一些贫民的DI。该应用程序正在增长，需要更好的测试支持，并开始呼吁IoC容器。

我阅读的所有内容（例如这个SO问题）都指出，我应该在应用程序根处配置IoC。如果我直接从控制器操作中使用存储库并需要在控制器级别进行DI，那么这对我来说是有意义的，但我没有这样做。看起来我想要将我的组合根放在我的服务层中。我一直在想，我不希望我的web.config（或另一个配置文件）在UI层中提到/看到/听到存储库、信用卡处理器等。

我这样考虑是否正确，还是我只需要克服这个问题？

- ericvg

Answer 1

我和你的情况相同，我是这样解决的。

我使用的一般规则是，无论有没有global.asax或类似的东西，都需要执行注册IoC组件的代码。换句话说，您需要为每个不同的正在运行的进程运行它（即网站在一个进程中，服务在另一个进程中）。

在我的情况下，我首先在mvc网站的global.asax中执行此操作，然后再在服务器上执行一次。在这种情况下，所做的注册将在服务和网站之间有所不同。

此外，我还做了一件事。由于我在mvc应用程序和服务之间重用组件（例如日志记录），因此我有第三个核心组件，用于为系统注册核心IoC组件，并且该组件由网站和服务的注册调用。因此，任何在服务和网站之间共同的内容都放入核心注册中，而任何不同的内容都放入“接口”特定的注册中。

希望对您有所帮助。

- anthonyv

Answer 2

你只需要克服它 :)

将组合根放在应用程序根中并不需要在web.config中有很多DI容器的东西。如果你愿意，你可以这样做，但这是可选的。当将组合根放在应用程序根中时，不可选的是你需要在Global.asax中编写一些DI代码。

你可能觉得这与你的控制器无关，因为它们非常简单，但这不是真正的重点。实际上，你（抽象的“你”）想要推迟耦合类直到最后负责的时刻。你越早耦合类型，你就越没有灵活性。

如果你在服务层中耦合类，那么你在那个时候做出了一个不可逆转的决定。如果以后发现你需要以不同的方式组合这些服务，你就不能这样做 - 除非重新编译。

如果这样做有很大的好处，我可以理解你为什么想这样做，但事实并非如此。你可以等到绝对必须这样做的时候再组合所有组件 - 这是在应用程序的入口点。

- Mark Seemann

Answer 3

从Java的角度来看，我使用Spring框架作为我的IoC容器。通过它，容器真正成为应用程序范围内的。虽然您可以为不同的层（持久性配置文件、服务配置文件、控制器配置文件等）拥有不同的配置文件，但所有对象（Java术语中的bean）都进入容器。

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

- D.C.