客户端上带有 IoC 的洋葱架构 [重复]答案

【问题标题】：Onion architecture with IoC on the client [duplicate]客户端上带有 IoC 的洋葱架构 [重复]
【发布时间】：2015-10-17 15:19:29
【问题描述】：

我的应用程序使用域驱动的洋葱架构。它有exact same layers as this。

但是，当我在客户端层的 mvc 应用程序中设置 IoC 依赖项时，我有点困惑。我应该从客户端层调用我的存储库接口之类的东西，还是应该像在典型的 3 层 n 层应用程序中那样通过业务层？这样，我的客户端层只会将业务接口注入其中，而不是存储库和业务接口。

如果我最终改变它，让客户端层只访问业务功能，我将不得不在业务层上执行 IoC，因为它使用数据存储库。

【问题讨论】：

【解决方案1】：

您的客户端层应该将存储库接口的实例注入业务层，以便业务层不知道任何基础架构实现，但具有实现存储库接口的实例，因此它可以通过它调用存储库。

【讨论】：

嗯，你能给我举个小例子吗，因为我认为我不完全理解你的意思。看起来你说的是我的 IoC 容器应该只在客户端上。但我不完全明白你的意思，因为我已经习惯了我的客户端层只与我的业务层对话，而我的业务层只与我的数据层对话。
是的，因为您牢记硬编码的 n 层架构 :-) 客户端层组成您需要的实例并注入它们。所以你创建了一个 XRepository，它实现了 IXRepository 接口，这个接口被 BL 引用，所以你可以例如通过构造函数将 XRepository 实例注入到 BL。
我想它终于成功了。 ICustomerRepository 被传递到我的 mvc 控制器的构造函数中，该构造函数被传递到我的 ICustomerBLL 的构造函数中。因此，我必须解决客户端 mvc 应用程序中业务和数据接口的依赖关系。这有意义吗？
是的，我就是这样做的。更准确地说，我有一个额外的 API 层，它执行所有依赖注入和实例创建，因此控制器操作只是对 API 方法的单行调用。但老实说，我认为没有必要。也许如果您的 api 将在 asp.net 之外使用。
太棒了！所以你的控制器很干净并且代码很少。感谢您的帮助！