问查询写入模型

EN

我要说的是，命令接口不应该被认为是支持查询的，为此编写模型不一定要向客户端应用程序公开。

然而，在第一个问题中您要寻找的概念是：

为了获取页面实体的最新状态，查询写模型是否在概念上是错误的？

似乎是“读您自己的写”，这可能是非常重要的一些应用程序。我想一个人可以提供一个缓冲区来记住自己的会话写。不过，我所做的有点不同。

我从命令接口以及查询接口返回时间戳(或支持>=比较的其他值)。时间戳与其他(更改的)内容一起从写入模型转发到读取模型。

然后，当需要读取我自己的写操作时，我的客户端查询有关>=的相关数据--它发出的最后一个命令返回的时间戳。通过这种方式，我知道查询正在报告客户端最新更改时的内容。

我不明白后续的问题：

如果我选择查询Read模型(根据CQRS旅程手册的典型实现)，我如何处理乐观并发？

正如@Alexus所说，阅读模式是只读的，所以不必担心多个作者。然而，它并不是完全只读的，因为它必须以某种方式从写模型中反复更新。乐观并发应该在内部由规范化的写模型SQL存储来处理，也应该由非规范化的读模型SQL存储来处理。(如果对非规范化读模型使用非SQL存储，您应该意识到，在实现最终一致性的过程中，用陈旧值响应读取模型查询与在最终一致性过程中响应不一致的混合值是有区别的。)

更新：

抱歉，我搞错了。乐观并发一词超载..。这个术语通常(在我看来)是指数据库内部发现的一种事务重叠能力。然而，CQRS使用这个术语来指客户端应用程序和命令服务器(以及查询服务器)之间的类似功能。您还使用命令提供时间戳(正如我前面所描述的)，它的形式是，如果时间戳过期，请命令失败/中止。请注意，建议每个聚合都有自己的细粒度时间戳，因此我们讨论的是对每个聚合使用我前面描述的逻辑。

因此，这将创建一个关于时间戳/版本号的完整循环或循环。当客户端应用程序执行第一个查询时，它会省略时间戳，尽管它会收到回时间戳；当它执行一个命令(很可能是基于它目前拥有的查询信息)时，它会传递带有标记的查询时间戳，以便在时间戳上终止。当命令完成时，它提供了一个时间戳，下一个查询可以使用这个时间戳来查看最后一个命令的结果是否在读模型中(或者等到这样)。查询返回新的时间戳，下一个命令基于这些最新的时间戳(如果是旧集，则为中止)，依此类推。(有时，如果UI知道有一段时间没有刷新，它可能会提前刷新。)

我认为您可以从整个系统的单个全局时间戳/版本号开始；让它正常工作，然后使时间戳更细粒度(例如，每个聚合实例)，以获得更好的并发性。在@JDT回答时，这已经是很复杂的事情了，如果您一直把它用于复制同一个聚合的命令处理器，那么情况就更复杂了。

概念上错了？我会说：“是的！”

看来你愿意做CRUD。这并没有本质上的错误。但在概念上不是CQRS。

如果你只需要CRUD来解决你的问题，就用CRUD吧。

不，读模型是用于读的，写模型是写

的

如果您的系统要求您使用CQRS (这是您真正应该认真考虑的事情)，您就不能使用写模型来获取UI中的最新数据。在设计应用程序时，它可以处理写操作与最终一致的读取模型之间的延迟。如果延迟时间很短(例如，2秒或更短)，您可以使用一个页面，该页面只需向用户显示已保存的更改的消息，从而只需防止用户看到不一致的数据。更长的延迟可能意味着“伪造”数据，方法是将数据保存在会话中并在其中显示数据，隐藏已编辑过且尚未一致的字段，等等。

使用读写模型进行“纯”CQRS对您编写应用程序的方式有非常大的影响。应该真正考虑应用程序是否足够大，以保证采用这种方法，因为在常规应用程序中，您认为理所当然的许多事情会变得不那么明显或完全困难。