CQRS 模式上的服务层答案

【问题标题】：Service Layer on CQRS patternCQRS 模式上的服务层
【发布时间】：2016-05-19 13:41:27
【问题描述】：

我正在尝试使用 CQRS 模式而不是存储库和洋葱架构而不是使用 MVC5 堆栈的 n 层来构建应用程序。

我现在有以下几层：

Web.Data - Contains DbContext 
Web.Model - POCO classes
Web.Service - Implementation of Commands and Queries using MediatR
   --Commands
   -----Request
   -----Handlers
   --Queries
   -----Request
   -----Handlers
Web.UI

我正在考虑将业务逻辑（例如验证）放在 Handler 类上，但我发现这些类可以直接访问 EF。它仍然是放置这些逻辑的好地方吗？

如果我有一个电子邮件逻辑或运输逻辑呢？在传统层上，它们自然会转到应用程序服务，并在该服务上注入存储库，它们将如何适应当前架构？我们不想走存储库路线，因为我们想将 EF 作为一个整体来利用，而不是进一步抽象它。

我是否应该有一个接受 MediatR 接口的传统服务层并让控制器具有服务接口？

【问题讨论】：

我的第一个问题：你们的模特只是纯粹的财产包还是他们有行为？如果是后者，您应该将业务逻辑放入其中。当然，例如，如果验证跨越多个模型/AR，您需要一个服务/外观。验证本质上是一种依赖，但你可以看看这个answer 以获得好的想法。
我建议您在决定与 Entity Framework 结婚之前获得一份婚前协议。它与具有美化建模界面的 DataSet 2.0 和一堆实际上不应该在应用程序层内完成的东西差不多。我恳请您将 EF 的使用限制在其 ADO.NET 生成器和 dto 水合中。像 Linq To Sql 一样对待视图和存储过程，你会避免痛苦。
@K.AlanBates 任何框架或技术都可能在不熟练的从业者手中引起问题。英孚也不例外。我认为使用 EF 构建的数以万计的成功系统不言自明。
@PhilSandler 第一个声明是不言而喻的，并不是我要说的。您的“成功”声明是不合格的。构建成功？成功的领域目标？成功到一些kpi？我说（并且一直声明）实体框架是构建团队背景下降低构建成本的一项有价值的技术，但是一旦您将系统移交给维护团队，它就与魔法（克拉克第三定律）没有区别。任何系统都可以支持大量的魔法，我尝试将魔法保留用于比节省一些打字更重要的事情。
@PhilSandler 确定它是（讨论这些的地方） OP 提到他想偏离 EF 擅长的范围，但说他正在使用实体框架。对我来说，这是一个完美的时机来提及“使用 EntityFramework = 会过得很糟糕”这就像你应该吃披萨的时候炸薯条

标签： c# entity-framework asp.net-mvc-5 cqrs

【解决方案1】：

处理程序类应处理命令并包含协调任务完成的逻辑。此逻辑可以包括对域模型的委托、持久性和检索，以及调用其他服务（例如运输或电子邮件）。请注意，命令处理程序只是应用程序服务的另一种形式。因此，它不应该直接访问 EF，也不能放置业务逻辑验证。

【讨论】：