我一直在阅读 CQRS 并发现许多原则很有价值。但是，我有一个主要的争论点。许多人谈论让读取模型查询直接映射到视图模型 dto。到目前为止，一切都很好。但是，我经常听到的“一个表或一个视图一个选择”从何而来？当然，有些屏幕非常容易映射 1-1。但我经常使用一些复杂的屏幕，这些屏幕会涉及对下拉列表中的参考数据、小部件等的多项选择...
我可以很容易地看到我的视图需要多个选择，也许有些需要加入或两个。
除了处理您的视图简单而扁平的完美世界场景之外，您如何避免这种情况？
问问题
1504 次
4 回答
6
但我经常使用一些复杂的屏幕，这些屏幕会涉及对下拉列表中的参考数据、小部件等的多项选择...
选择列表、小部件等。您可以将它们视为嵌套在另一个视图中的视图（如果它们已经是它们自己的部分视图，则可能很明显）。以这种方式查看时，他们每个人都可以有自己的查询。
于 2010-12-20T21:36:11.757 回答
2
答案是一个问题：“我对视图的非规范化是否足够？我可以预先计算更多吗？我可以更好地表示这些信息以便需要更少的查询吗？”
争取“1 个视图 == 1 个查询”。正如 qstarin 所说，查看！= 屏幕。
于 2010-12-20T21:57:41.957 回答
2
在我使用过的场景中，我们使用视图缓存作为我们希望渲染的对象的预先计算的视图。即使事件（我们使用 EDA）来自不同的域，我们也有维护视图缓存的处理程序，以便我们可以拥有我们希望以适合复合 UI 的状态呈现的信息。我们努力的目标是让“select *”或“select * where ID =”成为对视图缓存的唯一查询形式。有些页面有多个 DTO 正在呈现，但我们不必加入它们。如果我们觉得有必要加入，我们会在预计算阶段这样做，当时我们正在处理包含我们希望存储在视图缓存中的信息的消息。
于 2010-12-22T13:54:59.367 回答
0
您可以使用Denormalization避免这种情况。您应该使所有复杂的数据成为平面视图（无连接）。另请查看First normal form (1NF or Minimal Form)。
In CQRS it's used to make read side as fast and simple as possible. As a result it can be scaled horizontally.
于 2010-12-31T09:26:17.870 回答