洋葱架构我们应该将域模型注入表示层吗？

Question

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

1. 洋葱建筑能否在没有IOC的情况下工作，如果是，它是否理想？
2. 如果用户界面不了解实际的实施情况，我们假设我们选择IOC 域服务，我们应该将相同的原则应用于域模型 他们自己将模型注入UI而不是引用 他们直接？

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

Answer 1

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

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

我认为Palermo为绕过一个层提供了空间，因为他希望能够在Controller中操作域模型和域服务。据我所知，域驱动设计只有在逻辑不能完全适合域模型时才会创建域服务。如果是这种情况，那么域服务和域模型实际上不是2个单独的层。相反，最好将它们视为单个业务层。如果它们都是同一层，那么是否可以在Controller中使用它们的问题就会自行解决。然后你可以毫无矛盾地说，外层应该被约束到与洋葱中的下一层交谈。

Answer 2

首先，请记住Onion Architecture (OA)与应用程序设计风格无关，因此没有什么可以阻止您将域注入UI。其次，链接的文章指出IoC是核心，所以你不会想要没有它。我也猜测你在谈论你的域名实体 - 你域中有数据/状态的那些东西。

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

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

因此，总而言之，除非您需要在您的域实体上隐藏逻辑，或者存在令人信服的体系结构原因（例如，您将这些服务器从服务器转移到远程客户端或者您想要添加UI您的属性的特定属性，以影响验证或标签显示），您应该直接在“应用程序/ UI”层中引用您的具体域实体。