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

Question

阅读 a SO question ，我意识到我的读取服务可以提供一些更智能的对象，例如 ViewModel，而不是普通的 DTO。这让我重新考虑读取服务返回的对象应该提供哪些信息
之前，仅使用 DTO，我的读取服务只是将数据库查询的平面 View 映射到类似哈希的结构中，具有最小的规范化并且没有行为。
但是，我倾向于将 ViewModel 视为“更智能”的东西，它可以生成数据库未提供的信息，例如状态图标、计算值、重新格式化的值、默认值等。
我开始看到，如果我将我的通用 读取服务接口(interface) 仅返回 ViewModel:

(1) Should I plan some design restriction for the ViewModels returned by my CQRS? Like making sure that their construction is almost as fast as a plain DTO?

(2) DTOs by nature are easily serialized and ready to be sent to an external system in a SOA architecture or embedded into a message. Does this mean that using ViewModels will have a negative impact on my architecture?

(3) Which type of ViewModels should I keep outside my Read Services?

(4) Should I expect all ViewModels to be retrieved from Read Services?

过去，我实现了一些需要多个查询的 ViewModel。我想在 CQRS 中，这是一种设计味道，因为它们提供的所有东西都应该只在一个查询中。
我正在开始一个新项目，我认为任何查询都会返回聚合对象或 DTO。从现在开始，ViewModel 开始发挥作用。我想知道:

(5) Should I plan that queries within my architecture will yield two type of objects (ViewModels+Aggregates) or three (+DTO)?

Answer 1

View 模型 (VM) 服务于一个主节点: View 。我们通常认为 VM 是一个非常愚蠢的对象，因此在这方面，VM 和 DTO 之间没有技术差异，只是它们的目的和语义不同。

如何构建 VM 是一个实现细节。一些 VM 是预先生成并存储在 VM 存储库中的。其他是由服务(或查询处理程序)通过直接查询数据库或查询其他存储库/服务然后组装结果来实时构建的。没有对错之分，也没有关于如何去做的规则。它归结为偏好。

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

不要让技术细节使您的设计复杂化。正确的设计更多的是关于高级结构而不是低级实现。使用 CQRS 是因为拥有读取模型可以简化您的应用程序，而不是出于其他原因。旨在简化和清洁代码，而不是要求“如何”配方的严格规则。