中间层/后端服务的洋葱架构答案

【问题标题】：Onion architecture for middle tier/backend services中间层/后端服务的洋葱架构
【发布时间】：2012-10-03 15:46:00
【问题描述】：

我目前正在处理来自 J.Palermo 的 Onion Architecture。在我的情况下，我在实施它时遇到了一些麻烦。这种架构是否适合“业务较少”的网站，也就是服务混搭？

这是我的情况：

我们有许多后端服务（在 WCF 中），每一个都公开独立的业务数据（营销、帐户、报价、CMS ...）。我们的许多 MVC 网站“只是”使用这些服务来呈现页面。所有业务逻辑都在服务中，网站仅限于呈现逻辑。网站中没有数据库访问权限。然而，一些业务数据可以合并到一个复合实体中进行展示（例如将内容页面链接到报价）。我想把这个逻辑放在服务层下。

编辑： 我应该为映射后端/中间层服务结果/操作创建域模型吗？也许这里的业务逻辑只是合并不同来源的数据？

谢谢，

【问题讨论】：

标签： asp.net-mvc domain-driven-design soa onion-architecture

【解决方案1】：

如果所有业务逻辑都在 WCF 服务中，我将很难理解具有域模型的核心项目的意义（它会做什么？）。我假设您没有在这些服务之上添加一层业务逻辑来组合多个操作？如果不是，我会说洋葱架构不适合这种情况。

【讨论】：

我有一些用例需要合并来自不同业务领域的数据，但我认为它与表示逻辑更相关。
嗯，保持控制器精简并避免在其中放置与表示不严格相关的任何内容是一种好习惯，但是您可以使用单独的服务包装器或帮助器类来做到这一点，听起来仍然像洋葱架构一样矫枉过正。如果它不会增加价值，我们不应该盲目地实现一个模式。
显然，我不谈论 mvc 最佳实践（DI、瘦控制器、可测试性......）。见编辑
我假设您正在使用 Automapper 或类似的地图视图模型。如果您想保持简单，我想您可以直接映射到服务中的对象。如果您看到映射到中间实体的价值，那么也许这就是拥有域模型的原因。如果是我，我可能会选择前一条路线以保持简单。我将我的 Automapper 代码保留在 UI 项目中，因为它是从视图模型映射的呈现问题。在此基础上，我仍然认为不需要洋葱架构。

【解决方案2】：

我会说 WCF 实际上是其他应用程序的域服务。实际上，您只是将 Onion 拆分到多个应用程序中。

【讨论】：