3

我一直在阅读 CQRS 并发现许多原则很有价值。但是,我有一个主要的争论点。许多人谈论让读取模型查询直接映射到视图模型 dto。到目前为止,一切都很好。但是,我经常听到的“一个表或一个视图一个选择”从何而来?当然,有些屏幕非常容易映射 1-1。但我经常使用一些复杂的屏幕,这些屏幕会涉及对下拉列表中的参考数据、小部件等的多项选择...

我可以很容易地看到我的视图需要多个选择,也许有些需要加入或两个。

除了处理您的视图简单而扁平的完美世界场景之外,您如何避免这种情况?

4

4 回答 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 回答