3

我正在尝试为 ASP.Net MVC 5 项目实现 Onion 架构。我已经看到了应该注入服务而不是实例化服务的观点，如果我错了，请纠正我，Jeffrey Palermo 表达的想法（http://jeffreypalermo.com/blog/the-onion-architecture-part-3/）是任何外层都应该能够直接调用任何内层。所以我的问题是

  1. 洋葱架构可以在没有 IOC 的情况下工作吗？如果可以，是否理想？
  2. 假设我们使用 IOC，如果 UI 不应该知道域服务的实际实现，我们是否应该将相同的原则应用于域模型本身，例如将模型注入 UI 而不是直接引用它们？

我理解为什么某些解决方案将 IOC 应用于域服务但直接在控制器中访问域模型。

4

2 回答 2

3

OA 可以被认为是 n 层架构 + 依赖注入——所以如果没有 IOC，你将很难实现 OA。

关于使用任何内层的外层，我个人在这一点上不同意巴勒莫。我认为外层应该被限制在与下一层一起工作（重申：不应允许外层绕过一层）。我曾经在 twitter 上问过他这个问题，他说数据访问实现代码与表示层一起工作可能不是一个好主意（请记住，实现代码位于他架构的外缘）。

我认为巴勒莫为绕过层腾出空间正是因为他希望能够在控制器中操作域模型和域服务。据我了解领域驱动设计，领域服务仅在逻辑不完全适合领域模型时创建。如果是这样的话，那么域服务和域模型并不是真正的 2 个独立的层。相反，最好将它们视为单个业务层。如果它们都是同一层，那么是否可以在 Controller 中同时使用它们的问题就会自行解决。然后你可以毫无矛盾地说外层应该被限制在与洋葱中的下一层对话。

于 2014-01-13T17:32:48.727 回答
1

首先，请记住洋葱架构 (OA)与应用程序设计风格无关，因此没有什么能阻止您将域注入 UI。其次，链接的文章指出 IoC 是核心，所以你不会想尝试没有它。我还推测您正在谈论您的域实体 - 那些在您的域中具有数据/状态的事物。

OA 是关于保护您的域（业务规则、实体等）免受基础设施变化的变幻莫测，而不是相反。通过使用接口访问您的域，您所购买的只是额外的代码和间接。问问自己这个问题 - 如果我的域发生变化（您业务的核心），期望我的用户界面不会发生变化是否现实？换句话说，如果您的业务规则发生变化，如果涉及添加或删除字段或整个业务线，用户可能希望看到 UI 中反映的内容。

现在问这个问题的反面——如果我从 Oracle 更改为 NoSQL，我的域代码会更改吗？注入您的基础设施负载服务旨在给您“否”的答案。这大概意味着更容易维护和更稳定的代码。

所以，总而言之，除非你需要在你的域实体上隐藏逻辑，或者有一个令人信服的架构理由反对它（例如，你将这些从你的服务器扔到远程客户端，或者你想添加特定于 UI 的属性到您的属性以影响验证或标签显示），您应该继续在“应用程序/UI”层中直接引用您的具体域实体。

于 2014-03-11T17:39:07.053 回答