我正在尝试使用 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
我曾考虑将业务逻辑(例如验证)放在处理程序类上,但我认为这些类可以直接访问 EF。它仍然是放置这些逻辑的好地方吗?
如果我有电子邮件逻辑或运输逻辑怎么办?在传统层上,它们自然会转到应用程序服务,将存储库注入(inject)该服务,它们将如何适应当前架构?我们不想走存储库路线,因为我们想将 EF 作为一个整体来利用,而不是对其进行更多抽象。
我是否应该有一个接受 MediatR 接口(interface)的传统服务层,而让 Controller 有服务接口(interface)?
最佳答案
处理程序类应该处理命令并包含协调任务完成的逻辑。此逻辑可以包括对域模型的委托(delegate)、持久化和检索,以及调用其他服务(例如运送或电子邮件)。请注意,命令处理程序只是应用程序服务的另一种形式。因此,它不应该直接访问 EF,也不应该放置业务逻辑验证的地方。
关于c# - CQRS 模式上的服务层,我们在Stack Overflow上找到一个类似的问题: https://stackoverflow.com/questions/35294290/