相关疑难解决方法(0)

阅读一个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)？

假设读模型ProductCatalogueItem是从聚合/写模型构建的，与写模型分开存储，并包含每个可供销售的产品，并具有以下属性：

• 基本：product_code，name，price，number_of_available_stock，
• 文档：short_description、description、...
• 产品特性：weight, length, depth, width, color,...

并且，有两种观点：

• 产品列表包含可用产品报价的列表/表格/网格，并且视图仅需要以下基本属性：product_code, name, price, number_of_available_stock,
• 显示所有属性的产品详细信息 - 基础知识、文档、产品特性。

自然地，想到了两个 ViewModel：

• ProductCatalogueListItem仅包含基本属性，
• ProductCatalogueItemDetails包含所有属性。

现在，..有两个选择（我可以看到）。

1. ViewModel 是 ReadModel 的 1:1 表示

因此，有两种读取模型，而不是一种，ProductCatalogueListItem并且ProductCatalogueItemDetails。并且，读取服务将有两种方法：

• List<ProductCatalogueListItem> searchProducts(FilteringOptions),
• ProductCatalogueItemDetails getProductDetails(product_code)。

并且，控制器直接返回这些模型（或者映射到传输层的 dto）。

这里的问题是过滤，..读取服务是否应该在不同的读取模型上执行搜索查询，而不是从方法调用返回的模型？因为，ProductCatalogueListItem 没有足够的信息来执行过滤。

2. ViewModels 是 ReadModels 的另一个项目

读取服务有两种方法：

• List<ProductCatalogueItem> searchProducts(FilteringOptions),
• ProductCatalogueItem getProduct(product_code) …