我正在尝试为ASP.Net MVC 5项目实现Onion架构 . 我已经看到了服务应该被注入而不是实例化的意见，即使纠正我，如果我错了，Jeffery Palermo（http://jeffreypalermo.com/blog/the-onion-architecture-part-3/）表达的想法是任何外层应该能够直接调用任何内层 . 所以我的问题是
-
洋葱建筑能否在没有IOC的情况下工作，如果是的话，它是否理想？
-
假设我们选择IOC，如果UI不应该知道域服务的实际实现，我们是否应该将相同的原则应用于域模型本身，例如将模型注入UI而不是直接引用它们？
我理解为什么有些解决方案在域服务上应用IOC，但直接在控制器中访问域模型 .
2 回答
OA可以被认为是n层架构依赖注入 - 因此，如果没有IOC，您将很难实现OA .
关于使用任何内层的外层，我个人不同意巴勒莫的观点 . 我认为外层应该被限制为使用下一层（重申：不允许外层绕过一层） . 我曾经在twitter上问过他一次，他说数据访问实现代码与表示层一起工作可能不是一个好主意（记住实现代码在他的架构的外围） .
我认为Palermo为绕过一个层提供了空间，因为他希望能够在Controller中操作域模型和域服务 . 据我所知，域驱动设计只有在逻辑不能完全适合域模型时才会创建域服务 . 如果是这种情况，那么域服务和域模型实际上不是2个单独的层 . 相反，最好将它们视为单个业务层 . 如果它们都是同一层，那么是否可以在Controller中使用它们的问题就会自行解决 . 然后你可以毫无矛盾地说，外层应该被约束到与洋葱中的下一层交谈 .
首先，请记住Onion Architecture (OA)与应用程序设计风格无关，因此没有什么能阻止您将域注入UI . 其次，链接的文章指出IoC是核心，所以你也赢了，你也猜测你在谈论你的域实体 - 那些在你的域中有数据/状态的东西 .
OA旨在保护您的域（业务规则，实体等）免受基础设施变更的影响，而不是相反 . 通过使用接口进入您的域，您所购买的只是额外的代码和间接 . 问问自己 - 如果我的域名发生了变化（业务的核心），那么期望我的用户界面不会是现实的吗？换句话说，如果您的业务规则发生变化，用户可能希望看到在UI中反映的内容，如果涉及添加或删除字段或整个业务线 .
现在问一下这个问题的反面 - 如果我从Oracle改为NoSQL，我的域代码会改变吗？注入您的基础设施负载服务旨在为您提供“否”的答案 . 这可能意味着更容易维护和更稳定的代码 .
因此，总而言之，除非您需要隐藏域实体上的逻辑，或者存在令人信服的体系结构原因（例如，您将这些服务器从服务器转移到远程客户端，或者您想要添加特定于UI的属性要使您的属性影响验证或标签显示），您应该直接在“应用程序/ UI”层中引用具体的域实体 .