文档建议反馈控制台
首页
学习
活动
专区
工具
TVP
最新优惠活动
文章/答案/技术大牛
发布
精选内容/技术社群/优惠产品,尽在小程序
立即前往

在CQRS中,我的阅读方应该返回DTO还是ViewModels？

在CQRS（命令查询职责分离）架构中，阅读方（查询）应该返回ViewModels。

CQRS是一种将命令（写操作）和查询（读操作）分离的架构模式，它可以帮助提高应用程序的可扩展性和性能。在CQRS中，查询方的主要目的是从数据存储中获取数据并将其呈现给用户。

ViewModels是一种用于表示数据的模型，它们通常包含一组属性，这些属性可以直接映射到用户界面（UI）组件。在CQRS中，使用ViewModels可以确保查询方返回的数据与UI组件之间的紧密耦合，从而提高应用程序的可维护性和可扩展性。

另一方面，DTO（数据传输对象）是一种用于在不同层次或模块之间传输数据的对象。DTO通常包含一组属性，这些属性可以在不同的层次或模块之间传输，而不需要考虑它们如何在UI中呈现。

因此，在CQRS中，使用ViewModels可以更好地满足查询方返回数据与UI组件之间的紧密耦合需求，从而提高应用程序的性能和可维护性。

推荐的腾讯云相关产品：

  • 腾讯云云巢（TKE）：一种基于Kubernetes的容器管理平台，可以帮助用户快速构建、部署和管理微服务应用程序。
  • 腾讯云Serverless架构：一种基于事件驱动的计算服务，可以帮助用户在不需要考虑服务器基础设施的情况下开发和部署应用程序。
  • 腾讯云API Gateway：一种用于管理API的服务，可以帮助用户快速构建、部署和管理API，并提供安全、稳定和可扩展的API访问。

产品介绍链接地址：

相关搜索:在Angular 8中，我应该将Spring Boot rest调用返回的数据定义为接口还是类？我应该使用excel还是在MySQL中创建自己的透视表查询在Python中，我应该如何注释返回ctypes数组的函数？laravel 8在集合中返回错误的id - bug还是我错了？我应该在搅拌机中还是在Unity中创建带有子弹的射击动画我应该直接存储字符串还是将它们的数字标记存储在elasticsearch中在JAVA中，我应该把函数的返回值放在哪里？我应该在我的Git库中还是在专用的父目录中运行"pip install -r requirements.txt“？在C++多线程应用程序中，我应该传递lambda还是带参数的函数？我应该将带有大孔的系列中的无序值存储在稀疏Vec中还是将HashMap存储在Rust中？我应该在params中发送所需的id，还是在request对象中作为property发送？在Java中,我应该为首先返回最大元素的PriorityQueue使用什么？我应该线性化还是尝试用gurobi在python中求解MINLP，还是尝试一种完全不同的方法？在Spring中，直接从服务返回ResponseEntity是更好的做法，还是应该在控制器中创建它？在Watson Discovery API中，我应该使用哪个结果来确定最相关的文档:得分还是置信度？在构建Outlook加载项时，我应该如何处理读取iframe中的cookies (第三方cookies)我应该在视图控制器中还是在单独的类中使用委托/通知模式编写NSTimer代码？我应该将Jquery文件放在我的Web服务器上,还是只在我的PHP文件中通过jquery.com引用它们,哪个更好？如果我真的不需要引用的数据，我应该懒洋洋地定义一个JPA ManyToOne，还是只在我的实体中映射原始id？在空间中移动多个对象(存储在VBO中)的最有效方法是什么？我应该使用glTranslatef还是着色器？
相关搜索:
页面内容是否对你有帮助？
有帮助
没帮助

相关·内容

从单体架构迁移到 CQRS 后，我觉得 DDD 并不可怕

为了实现读 / 写分离，在左边的写路径中，客户端向后端发送 DTO，对数据库进行 CUD（创建 / 更新 / 删除）操作，后端在处理完成后向客户端返回表示成功的 Ack 或表示失败的 Nak。...唯一的区别是在写路径上用消息代替了 DTO。消息包含动作和数据，而不是像 DTO 那样只包含数据本身。因此，我们可以在消息中携带特定域的动作，使后端更容易识别每个动作，并有一个相应的域实现。...在这个阶段，CQRS 中的 C 出现了，消息就是一种命令。然而，可扩展性问题仍未得到解决。 另外，虽然我们简化了 DTO，改为使用消息进行通信，但在读路径上我们仍然需要 DTO。还是以社交媒体为例。...读取时，客户端需要 DTO，所以后端可以在读路径上做一些专门针对读取的优化，比如从原来的域对象预先生成 DTO，并将 DTO 存储在专门的数据库中以供读取。...写应该专注于持久化，各种读视图不应该在写路径上处理。但是，读路径上只有读，谁该准备那些读视图？ 因此，完整的解决方案是这样的： 左边的写路径和右边的读路径已经在 CQS 部分介绍过了。

89140

在Avalonia项目中使用MediatR和MS.DI库实现事件驱动通信

Request 消息在 MediatR 中，有两种类型：IRequest 返回一个T类型的值。IRequest 不返回值。...这节直接复制MediatR 在 .NET 应用中的实践 - 明志唯新 (yimingzhi.net)，大家应该可以学到些什么：软件开发发展到今天，模式和理念不断在架构中刷新：从分布式到微服务，再到云原生...实施一个完美的 DDD 还是有难度的，现实中奋战在一线的 CRUD 程序员还是不少。那么在 CRUD 和 DDD 之间我们是否还有缓冲区呢？...微软的官方文档中对此做过如下陈述：CQRS 命令和查询责任分离数据存储的读取和更新操作分离的模式。 在应用程序中实现 CQRS 可以最大程度地提高其性能、可伸缩性和安全性。...命令可以放置在队列中进行异步处理，而不是同步处理。查询从不修改数据库。 查询返回的 DTO 不封装任何域知识。

17010

    • 手撸一套纯粹的CQRS实现

    关于CQRS，在实现上有很多差异，这是因为CQRS本身很简单，但是它犹如潘多拉魔盒的钥匙，有了它，读写分离、事件溯源、消息传递、最终一致性等都被引入了框架，从而导致CQRS背负了太多的混淆。...我的理解是，它分离了读写，为读写使用不同的数据模型，并根据职责来创建相应的读写对象；除此之外其它任何的概念都是对CQRS的扩展。...public interface ICommand { } 与Command对应的有一个CommandHandler，Handler中定义了具体的操作。...) { this.Dto = dto; } public CreateBookDto Dto { get; set; } } 我不知道这里直接使用DTO对象来初始化是否合理...该实例的完整代码在github上，感兴趣的朋友请移步>>https://github.com/qifei2012/sample_cqrs 如果代码中有错误或不合适的地方，请在评论中指出，谢谢支持。

    63210

    从单体架构迁移到 CQRS架构

    为了实现读 / 写分离，在左边的写路径中，客户端向后端发送 DTO，对数据库进行 CUD（创建 / 更新 / 删除）操作，后端在处理完成后向客户端返回表示成功的 Ack 或表示失败的 Nak。...通常，在 restful API 中，2xx 表示成功，4xx 表示失败。右边的读路径只是通过读请求来获得相应的 DTO。 再从客户端的的角度来说下 DTO 的含义。...在这个阶段，CQRS 中的 C 出现了，消息就是一种命令。然而，可扩展性问题仍未得到解决。 另外，虽然我们简化了 DTO，改为使用消息进行通信，但在读路径上我们仍然需要 DTO。还是以社交媒体为例。...读取时，客户端需要 DTO，所以后端可以在读路径上做一些专门针对读取的优化，比如从原来的域对象预先生成 DTO，并将 DTO 存储在专门的数据库中以供读取。...写应该专注于持久化，各种读视图不应该在写路径上处理。但是，读路径上只有读，谁该准备那些读视图？ 因此，完整的解决方案是这样的： 左边的写路径和右边的读路径已经在 CQS 部分介绍过了。

    45920

    浅谈命令查询职责分离(CQRS)模式

    这里面很重要的一个问题是，系统中的读写频率比，是偏向读，还是偏向写，就如同一般的数据结构在查找和修改上时间复杂度不一样，在设计系统的结构时也需要考虑这样的问题。...并且在系统的演化中能够保持高度的灵活性，能够防止出现CRUD模式中，对查询或者修改中的某一方进行改动，导致另一方出现问题的情况。 逻辑清晰，能够看到系统中的那些行为或者操作导致了系统的状态变化。...在整个数据管理场景中的特定模块中CQRS可能比较有用。但是在有些地方使用CQRS会增加系统不必要的复杂性。...四 CQRS与Event Sourcing的关系 在CQRS中，查询方面，直接通过方法查询数据库，然后通过DTO将数据返回。...在实际的应用中，这一块就是直接对DB进行查询，然后通过DTO对象返回，这个DB可能是应对特定场景的报表数据库，这样可以提升查询性能。

    2.1K40

    DDD-CQRS能解什么问题

    事件源不是必须项， 读写分离 如果一个方法修改了对象的状态，就是一个命令，不应该返回数据 阻抗：创建资源的时候，不是要返回资源id吗（这个不是重点可以忽略） 如果一个方法返回了数据，该方法就是一个查询...，不应该直接或间接的修改对象的状态 阻抗：现在有些方法中在查询的时候进行了懒删除 CQRS期望解决的问题 类似懒删除这种导致的数据不一致，难以排查的问题 使用同一个领域对象来进行数据读写可能会遇到资源竞争的情况...遵循聚合根的定义，必须与对象的组合区分开，对象组合考虑用DTO或者其他 我们再来回顾下聚合根。...边界内的内容具有一致性：在一个事务中只修改一个聚合实例。如果你发现边界内很难接受强一致，不管是出于性能或产品需求的考虑，应该考虑剥离出独立的聚合，采用最终一致的方式。...像商品详情页这种应该使用DTO来组合。

    1K10

    DDD落地之仓储

    至于应用仓储选型是mybatis还是jpa，文中会进行分析，请各位仔细阅读本文。...虽然贫血模型有很大的缺陷，但是在我们日常的代码中，我见过的99%的代码都是基于贫血模型，为什么呢？...接口名称不应该使用底层实现的语法 定义仓储接口，接口中有save类似的方法，与面向集合的仓储的不同点：面向集合的仓储只有在新增时调用add即可，面向持久化的无论是新增还是修改都要调用save 出参入参不应该使用底层数据格式...而往往功能迭代过程中，数据修改的逻辑还是复杂的，因此建模也都是针对于增删改数据而言的。 那么查询数据有什么原则吗？ 构建独立仓储 查询的仓储与DDD中的仓储应该是两个方法，互相独立。...它明确表明聚合所必需的数据操作。 仓储用于管理单个聚合，它不应该控制事务。 ORM框架选型在迁移过程中不可决定性因此，可以嫁接转换器，但是还是优先推荐JPA。

    1.1K31

    一文带你落地DDD

    2.4.3.命令和查询职责分离--CQRS 一个对象的一个方法修改了对象的状态，该方法便是一个命令(Command)，它不应该返回数据，声明为void。...的实现，转换内部模型和外部模型，调用pay接口，返回内部模型dto 将原先业务中调用rpc的地方改成adapter 单测对比rpc和adapter，保证正确性 3.4.3....至此，原biz里的大多数类已迁移完成。 四.迁移过程中可能存在的疑问 迁移过程中一定会存在或多或少不清楚的地方，这里我分享一下我在迁移的过程中遇到的问题。...设想一下，你现在需要调用rpc接口，返回的字段有100，你要取其中50个字段。隔了一段时间，调用方改了接口逻辑的返回，数据被包含在实体内。而你调用这个接口的地方特别多，改动就很大了。...8.查询逻辑单独开设一个repository，还是可以在聚合根的仓储中，划分的依据是什么 单独开设一个仓储。

    77620

    3种CQRS架构模式

    简单来说，这个原则是说程序应当要么修改系统（Command），要么返回查询结果(Query)，软件中应当保持命令与查询的分离。...尽管 Martin Fowler 在他 2005 年的博客文章中也提到，这种分离并非总是可能的，一个很好的例子是返回一个刚插入的记录的 id。...单数据库 CQRS 单一数据库CQRS 模式没有正式名称，Mattew Renze 在他的课程Clean Architecture 中将其命名为单一数据库 CQRS，我也选择这个命名。...双数据库 CQRS 在“双数据库”方式中，我们需要两个数据库，一个用于写操作，一个用于读操作。命令端使用针对写操作优化的数据库。查询端使用针对读取操作优化的数据库。...与前面两种方式相比，事件源存储数据的思路完全不同。 在事件源方法中，我们并不只存储实体的当前状态，而且将实体发生的每一个状态作为快照来存储。

    38520

    整洁架构、DDD 和 CQRS 简介

    在这篇文章中，Bob 大叔强调了所有前身架构和清洁架构都具备的五个品质： 框架独立性：架构与第三方框架解耦。 可测试：该架构易于编写单元测试。...查询通过 DTO 将数据返回到表示层。 修改系统的高级操作不应返回数据。这些应该会产生副作用，修改系统的状态，然后完成。这些被称为命令。...在实践中，命令可能会返回一小部分元数据，例如新创建的实体的 ID，但仅此而已。命令也可能返回 ack/nack 响应。 命令执行的另一个结果可能是错误条件，在这种情况下，命令应该抛出异常。...返回的 DTO 上的属性的结构接近于第一范式，因为数据可能会从非规范化的数据库查询中返回，并且返回的 DTO 的结构通常会匹配用户的屏幕或某些可由用户使用的规范模型任何客户。...最后，我研究过的大多数专家都同意 CQRS 可以在不使用事件溯源的情况下提供巨大的好处。这是我建议您谨慎行事的另一个领域，因为这些高级模式不适合胆小的人。

    4.2K20

    科普 | 简述3种CQRS架构模式

    简单来说，这个原则是说程序应当要么修改系统（Command），要么返回查询结果(Query)，软件中应当保持命令与查询的分离。...尽管 Martin Fowler 在他 2005 年的博客文章中也提到，这种分离并非总是可能的，一个很好的例子是返回一个刚插入的记录的 id。...单数据库 CQRS 单一数据库CQRS 模式没有正式名称，Mattew Renze 在他的课程Clean Architecture 中将其命名为单一数据库 CQRS，我也选择这个命名。 ?...双数据库 CQRS 在“双数据库”方式中，我们需要两个数据库，一个用于写操作，一个用于读操作。命令端使用针对写操作优化的数据库。查询端使用针对读取操作优化的数据库。 ?...有多个为读优化的数据存储。 但在另一方面，这种方式实现很复杂，如果你不能从其中受益，那么用这个模式可能适得其反。 小结 CQRS 真正的威力在于可以对写和读操作进行不同的优化。

    1.4K10

    耿大侠 Diss国外架构师文章《From CQS to CQRS》

    似曾相识 最近在InfoQ上看到一篇谈论命令模式与CQRS架构的译文《From CQS to CQRS》（建议先阅读此文，本文会针对该文的一些观点进行探讨），文章从命令模式谈起，然后提出了命令模式的升级版...应该说两者是因为遵循了同样的OO设计准则才得到了如此高度的一致，可见优雅的设计都是相似的，模式之所以成为模式是有必然性的。 命令模式“错”了吗？...然而文章对命令模式的diss是站不住脚的，因为即使按照作者推荐的方式将所谓变化的部分（即“数据”）抽离到一个DTO中，在调用端依然需要实例化它，为其设定各种参数，这些参数天然就是执行业务的前提，无论采用何种设计...，作为下达命令的一方“把要干的事情讲明白”是最起码的“份内事”，所以在命令类的构造函数上传递参数和剥离到一个单独的DTO中包裹数据没有任何本质的区别，后者的做法反而有“从富领域模型向贫血的领域模型开倒车...而另一方面，人们也认识到命令模式具有广泛的适用性，具备在更高级别的架构模式中扮演核心角色的能力，但是将命令模式提升到更加通用和完备的层面还需要解决以下一些问题： 1.

    30930

    译《领域驱动设计之PHP实现》架构风格（中）

    它的主要目的是向用户UI层呈现模型，同时在模型每次更新后刷新UI的呈现形式。一般来说，视图层接收的对象 – 通常是一个数据传输对象（DTO）而不是模型层实例 – 从而收集被成功呈现的所有必需信息。...为什么要创建一个 DTO 而不是把模型实例直接交给视图层？ 简短来说，还是关注点分离。让视图层方便直接使用模型实例将导致视图层与模型层间的紧耦合。...以 MVC 为例，先前例子中的PostRepository类应该放在领域模型当中。...当这些技术被滥用时，对 UI 视图层的构建将变得非常痛苦。我们应该权衡是该用应用服务返回领域实例还是某些 DTO 。...命令查询分离 提出一个问题不应该改变对应的答案 – Bertrand Meyer 这种设计原则提出每个方法应该要么是执行动作的命令，要么是返回数据给调用者的查询，而不是两者都是 – 维基百科 CQRS谋求一种更为激进的关注点分离

    94130

    从横切到纵切，架构模式CQRS，提高系统进化能力

    再谈表现力 在领域设计：聚合与聚合根聊到了表现力问题，「数据设计」的表现力要弱于「对象设计」！相对应的，其实「数据展现」的表现力也是弱于「对象设计」的！ 我们还是以订单来举例！...会对该事件进行处理，比如处理成便于展示的模型，存储到ReadDB中 客户端可以对服务端发送查询，服务端直接从ReadDB中获取数据，构建QueryModel返回 这又什么优势呢？...对于普通分层架构来说，在保存订单时需要一个DTO用于存储相关信息，然后转成多个对应的Model来进行持久化；而查询订单的时候，你需要查询出多个Model，然后组装成另一个DTO来存储查询的信息，因为展示的时候可能要展示更多的信息...那存在读库中的数据结构就可以完全按照展示逻辑来优化，比如：我可以有一张订单展示表，表中包含了买家信息和卖家信息。在展示时，直接查询这张表就可以了，不需要和用户表进行关联查询，提高了数据读性能。...当需要对ReadDB中的数据进行恢复操作时，可以通过命令重演的方式来恢复。 不过你应该发现问题了，命令重演的方式性能上有问题。所以我们可以参考Redis，使用快照+事件溯源的方式来存储。

    91220

    程序员除了会CRUD之外，还应该知道什么叫CQRS！

    阅读本文约需要5分钟 今天主要跟大家分享一下什么是 CQRS，以及在项目中如何去使用。 1....然后通过业务层来处理业务逻辑，将处理结果封装成DTO对象返回给控制层，再通过前端渲染。反之亦然。 ?...首先有几个概念需要介绍一下，CQRS 模式中，首先需要有 Command，这个 Command 命令会对应一个实体和一个命令的执行类。...除此之外，CQRS 还可以用在任务调度模块中，不同的任务可以包含不同的 Command，实际中运用是非常广泛的。 5....在 CQRS 中，所有的涉及到对 DB 的操作都是通过发送 Command，然后特定的 Command 触发对应事件来完成操作，也可以做成异步的，主要看业务上的需求了。

    50150

    微服务架构下如何解耦，对于已经紧耦合下如何重构？

    简单来讲，消息集成，异步，彻底解耦，消息发布订阅，事件链是EDA整个架构的核心。但是在EDA包括CEP复杂事件处理，在使用的时候首先还是应该了解清楚其和传统流程驱动在业务分析方法上的区别。...这些都是在复杂事件分析中必须考虑的内容之一。 ? 从EDA事件驱动到CQRS ?...在CQRS中，查询方面，直接通过方法查询数据库，然后通过DTO将数据返回，这个方面的操作相对比较简单。...在命令查询职责没有分离的时候，可以看到一方面是模型本身的扩展性受到影响，另外一方面是原有的领域模型本身偏重，而且Entity实体本身也通过完整的DTO对象进行传输，这样在一些特殊的只需要更新或查询个别字段的时候...第二种即是只需要输入客户编码，微服务A返回最早的信用评级。 对于后者就是我们常说的粗粒度接口或领域服务，服务间的交互应该以领域服务和粗粒度服务为主，避免掉完全的数据库表的CRUD类服务接口。

    1.3K21

    程序员除了会CRUD之外，还应该知道什么叫CQRS！

    然后通过业务层来处理业务逻辑，将处理结果封装成DTO对象返回给控制层，再通过前端渲染。反之亦然。 ?...CQRS 的简单实现 说了这么多，该怎么实现呢？我们以上面提到的第一种方式为例：代码层面实现分离，数据库共享。这种方式在企业里也非常实用。...除此之外，CQRS 还可以用在任务调度模块中，不同的任务可以包含不同的 Command，实际中运用是非常广泛的。 5....在 CQRS 中，所有的涉及到对 DB 的操作都是通过发送 Command，然后特定的 Command 触发对应事件来完成操作，也可以做成异步的，主要看业务上的需求了。...最后，希望阅读完本文，能对你有所帮助。

    78130

    命令和查询责任隔离(CQRS)模式

    然而，在更复杂的应用程序中，这种方法可能变得笨拙。例如，在读取端，应用程序可能执行许多不同的查询，返回具有不同形状的数据传输对象(dto)。对象映射可能变得复杂。...解决方案 CQRS地址将读写分离到单独的模型中，使用命令来更新数据，使用查询来读取数据。 命令应该基于任务，而不是以数据为中心。...查询返回不封装任何域知识的DTO。 然后可以隔离模型，如下图所示，尽管这不是绝对的要求。 ? 拥有独立的查询和更新模型可以简化设计和实现。...读取模型没有业务逻辑或验证堆栈，只返回一个DTO以便在视图模型中使用。读模型最终与写模型保持一致。 必须将数据读取的性能与数据写入的性能分开调优，特别是当读取的数量远远大于写入的数量时。...与其他系统的集成，特别是与事件源的结合，其中一个子系统的时间故障不应该影响其他子系统的可用性。 这种模式不推荐在什么时候使用当: 域或业务规则很简单。

    1K20

    命令和查询责任分离 (CQRS) 模式

    上下文和问题 在传统的数据管理系统中，针对单个数据存储库中的相同实体集来执行命令（对数据的更新）和查询（数据请求）。 这些实体可以是关系数据库（如 SQL Server）中一个或多个表中的行的子集。...通常在这些系统中，所有创建、读取、更新和删除 (CRUD) 操作都应用于实体的相同表示法。 例如，通过数据访问层 (DAL) 从数据存储检索表示使用者的数据传输对象 (DTO)，并在屏幕上显示。...用户（可能是通过数据绑定）更新 DTO 的某些字段，然后 DAL 将 DTO 保存回数据存储中。 同一 DTO 可同时用于读取和写入操作。 该图说明了传统 CRUD 体系结构。 ?...与基于 CRUD 的系统中使用的单个数据模型相比，在基于 CQRS 的系统中使用分离的数据查询和更新模型可简化设计和实现。...读取模型不具有任何业务逻辑或验证堆栈，只返回 DTO 以在视图模型中使用。 读取模型最终与写入模型保持一致。

    1.1K50

    Clean Code系列之DDD分层参数转换

    在大多数项目中，这种代码很常见。 它有什么坏味道呢？ 分层穿透了，LoginRequest类本应该属于入口层，结果穿透到了service层。...2、没有达到DDD防腐层的意义，resource是隔离外部与核心业务的，但却变成了透传。 归属哪一层 在《再议DDD分层》[1]中，也讨论过。...controller的LoginRequest参数，会在TService中失效。在实现层面，LoginRequest本质上就是个DTO，传输数据。...这样有常见的两个问题 1、代码重复 《DDD实战指南》[2]中提出，我们引入CQRS架构中的概念，业务层有对应cmd和query对象。...需要有CreateArticleCmd和EditArticleCmd 而对于request dto的数量，从友好API角度，应该要有两个DTO，但如果是复杂的查询操作，query dto属性数量比command

    88020
    点击加载更多

    扫码

    添加站长 进交流群

    领取专属 10元无门槛券

    手把手带您无忧上云

    扫码加入开发者社群

    相关资讯

    热门标签

    更多标签

    活动推荐

      运营活动

      活动名称
      广告关闭

      腾讯云开发者

      扫码关注腾讯云开发者

      扫码关注腾讯云开发者

      领取腾讯云代金券

      热门产品

      热门推荐

      更多推荐

      Copyright © 2013 - 2024 Tencent Cloud. All Rights Reserved. 腾讯云 版权所有

      深圳市腾讯计算机系统有限公司 ICP备案/许可证号：粤B2-20090059 深公网安备号 44030502008569

      腾讯云计算（北京）有限责任公司 京ICP证150476号 | 京ICP备11018762号 | 京公网安备号11010802020287

      领券