3

我一直在阅读有关命令查询职责分离 (CQRS) 以及这种模式如何适合我们当前应用程序的信息。

说到读模型，我很清楚这些概念：“分离的读写数据模型”，“瘦读层返回的平面非规范化数据”。在大多数情况下，我们被困在同一个数据库（同一个读/写数据模型）上，运行在带有规范化表的 SQL Server 上，上面有通用的分层应用程序。

那么，在这种情况下应用 CQRS 是否有任何价值？如果是这样，在读取模型方面会是什么？

我想到的另一个问题是 MVC 应用程序从我的薄读取层请求信息，这些信息暴露了扁平视图。暴露的数据在呈现给用户之前仍然需要结构化（聚合），还是我错了？

最好的祝福

4

3 回答 3

5

CQRS 不需要有一个扁平化的读取模型；这是 CQRS 可以让您提供的好处，但它既不是必需的，也不是该方法的关键部分。

CQRS 是关于分离（如果你遵循名称，则为分离）。这是类固醇的命令查询分离原则（在我看来）。它为您提供的好处（在我的脑海中）是：

  • 将读操作与写操作分开；
  • 通过消息传递（例如命令、事件）在层之间进行通信，以便您的层是干净的；
  • 在您的层内分离，应用单一职责原则（例如，您的域应用业务逻辑，您的命令处理路由命令，您的非规范化器或事件处理程序（或任何您称之为的）将信息保存到您的读取存储等）
  • 允许您让团队成员在应用程序的不同部分上工作，而他们之间没有硬依赖；
  • 等等

因此，如果上述这些对您很重要或您想要争取的东西（并且您的应用程序的设计支持实现 CQRS），那么 CQRS 将为您提供好处和价值。

CQRS 有很多好处。这不是解决所有问题的正确解决方案，但是当星星对齐时，它是解决问题的好方法（即使您没有非规范化读取存储、事件存储或异步模型等）。

我希望这有帮助！

于 2013-04-04T12:54:42.703 回答
2

在我的职业生涯中，我曾多次与多个连接作斗争，以至于当像 CQRS 和 ES 这样的结构出现并提供了一种简洁的方式来简化读取方面时，我就跳了起来。好处是您可以获得许多好处，而不必实现通常与 CQRS 和 ES 相关的所有元素。只需将命令与查询分开就可以简化代码。但是，当您开始使用反规范化器为您的应用程序构建读取模型时，您会突然意识到您的应用程序是多么简单、干净和高性能。

如果有助于了解这种非规范化的“如何”工作，请查看这篇文章（它附带了一个代码示例以供参考）：How to build a master details view with CQRS and ES。我希望你觉得这有帮助。

于 2014-10-07T14:20:17.950 回答
0

如果它允许您停止从域对象投影读取模型，则在相同（例如）第三范式数据库上应用 CQRS 仍然可以在读取方面为您提供价值。

这也允许您更好地将您的域专门用于（我假设）事务处理，这意味着可能不需要许多关系。

于 2013-04-03T11:54:40.497 回答