使用ViewModel代替DTO作为CQRS查询的结果

Question

阅读一个SO问题,我意识到我的Read服务可以提供一些更聪明的对象,比如ViewModels而不是简单的DTO.这使我重新考虑Read Services返回的对象应提供哪些信息

以前,只使用DTO,我的读取服务只是将数据库查询的平面视图映射到散列状结构,具有最小的规范化和无行为.

但是,我倾向于将ViewModel视为"更智能"的东西,它可以生成数据库未提供的信息,如状态图标,计算值,重新格式化值,默认值等.

我开始看到一些ViewModel对象的构造可能会变得更复杂,并且如果我使我的通用ReadServiceInterface仅返回ViewModels ,则可能存在缺点:

(1)我应该为CQRS返回的ViewModels规划一些设计限制吗？就像确保它们的构造几乎和普通DTO一样快？

(2)DTO本质上很容易被序列化并准备好发送到SOA架构中的外部系统或嵌入到消息中.这是否意味着使用ViewModels会对我的架构产生负面影响？

(3)我应该在读取服务之外保留哪种类型的ViewModel？

(4)我是否应该从Read Services中检索所有ViewModel？

在过去,我实现了一些需要多个查询的ViewModel.在CQRS中,我认为,这是一种设计气味,因为它们提供的所有东西都只能在一个查询中.

我正在开始一个新项目,我认为任何查询都将返回聚合对象或DTO.从现在开始ViewModels发挥作用.我想知道:

(5)我是否应该计划在我的架构中的查询将产生两种类型的对象(ViewModels + Aggregates)或三种(+ DTO)？

Answer 1

视图模型(VM)为单个主服务器提供服务:View.我们通常认为VM是一个非常愚蠢的对象,因此在这方面,VM和DTO之间没有技术差异,只有它们的目的和语义不同.

如何构建VM是一个实现细节.某些VM预先生成并存储在VM存储库中.其他由服务(或查询处理程序)实时构建,可以通过直接查询数据库或查询其他存储库/服务然后汇总结果.没有对错,没有关于如何做的规则.归结为偏好.

在CQRS中,重要的部分是命令与查询的分离,即多个模型.关于您应该执行多少查询或者是否应该返回视图模型或dto,没有规则.只要您至少有一个专用于查询的读取模型,它就是CQRS.

不要让技术性问题使您的设计复杂化.正确的设计更多的是关于高层结构而不是低层实现.使用CQRS是因为拥有阅读模型可以简化您的应用,而不是出于其他原因.旨在简化和清理代码,而不是用于规定"如何"配方的严格规则.