许多与 CQRS(命令查询责任性)分离相关的博客圈文章似乎暗示所有屏幕/ View 模型都是平面的。例如姓名、年龄、出生地点等..因此建议在实现方面我们将它们放入快速读取源等中..每个 View 单个表mySQL等..然后使用原始SqlDataReader之类的东西将它们拉出来，踢掉讨厌的nhibernate ORM等等..
但是，虽然我同意域模型不能很好地映射到大多数屏幕，但我使用的许多屏幕都更具维度，而且我确信这很常见 在 LOB 应用程序中。
所以我的问题是人们如何处理屏幕，例如它显示客户详细信息的摘要，然后显示带有[更多详细信息]链接的订单列表等......
我考虑过对查询数据库进行直接的 SQL 查询，打破外部连接，这样就可以构建一个合适的 ViewModel 来查看，但这似乎有点矫枉过正？
或者(这开始让人感到恶心)在 CustomerSummaryView 表中有一个名为 Orders 的文本/大(无论数据库中的类型是什么)列，订单摘要屏幕网格的列由 分隔，行由 | 分隔。 。即使使用 XML 数据类型，它仍然感觉很脏。
关于最佳实践有什么想法吗？
最佳答案
是的，出现了困惑。它是这样发生的:首先，为了真正帮助新人了解 CQRS 的全部内容，并真正了解它与典型分层架构的不同之处，人们会说“你的 View 模型可以完全扁平”，以及“查询数据库中的每个 View 模型应该有一个表。”
但这实际上只是为了让大家明白......每个 View 模型必须只有一个表(尽管在大多数情况下您可能应该这样做)，这是不正确的。这些陈述试图表达的是:“您必须摆脱长期以来一直遵循的规范化规则。借助 CQRS 架构，您有机会在查询 channel 中创建数据库表这些表格完全根据您的 View 需求而设计，仅此而已。请确保您充分利用这一点。不要仅仅因为这是您习惯做的事情而半途而废地标准化这些表格。相反，继续做过去被认为是不可想象的事情，例如为每个 View 模型创建一个数据库表，或者使 View 模型表完全平坦。”
仍然存在像您这样的情况，最能满足您需求的架构将包含多个表。您甚至可以(上帝禁止)进行一两次连接。没关系，只要您确实设计了数据库表来服务于您的 View ，而不是相反。但要小心，很容易在规范化和在查询数据库中的许多 View 之间共享数据的过程中下滑。不要去那里......根本没有理由，而且它带来的成本大于 yield 。主要目标是:您的 View 逻辑应该非常简单。您希望智能规则位于房子的命令端，并在订阅者中保留一点，以填充查询 channel 中的数据。因此，从查询数据库读取数据并在屏幕上显示数据的代码应该非常简单(几乎与“被动 View ”一样简单)。
更新:作为对以下说法的进一步支持:只要您设计的数据库形状能够最好地服务于您正在实现的任务，就不会“禁止”执行某些联接，请考虑< OLAP。星型模式是一个完美的数据库模式示例，旨在支持读取，它非常适合 CQRS 的查询端，并且确实涉及连接。连接保持简单，它们的存在是为了进一步增强针对数据库执行的读取任务的目标。
关于nhibernate - CQRS - 查询端，我们在Stack Overflow上找到一个类似的问题： https://stackoverflow.com/questions/2273796/