CQRS - 读取模型 DTO 混乱
我一直在阅读 CQRS 并发现许多原则很有价值。然而，我有一个主要争论点。许多人谈论将读取模型查询直接映射到视图模型 dto。到目前为止，一切都很好。然而，我经常听到的“一个表或一个视图一个选择”从何而来？当然，有些屏幕很容易实现 1-1 映射。但我经常使用一些复杂的屏幕，这些屏幕涉及对下拉列表中的参考数据、小部件等进行多次选择...
我可以轻松地看到我的视图需要多次选择，也许有些需要连接或两个。
除了在您的观点简单而平坦的完美世界场景中工作之外，您还能如何避免这种情况呢？
I have been reading up on CQRS and find many of the principles to be valuable. However, I have one major point of contention. Many people talk about having the read model queries map directly to view model dtos. So far, so good. However, where does the "one table or one select per view" come from that I constantly hear? Sure, some screens map 1-1 very easily. But I routinely work with some complex screens that would involve multiple selects for things like reference data in drop down lists, widgets, etc...
I could easily see my views needing multiple selects, maybe some with join or two.
How can you possibly avoid this, aside from working with perfect world scenarios where your views are simple and flat?
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（4）
选择列表、小部件等。您可以将它们视为嵌套在另一个视图中的视图本身（如果它们已经是自己的部分，则可能很明显）。从这个角度来看，他们每个人都可以有自己的查询。
Select lists, widgets, etc. You can view these each as a view themselves nested in another view (possibly obvious if they are already their own partial). When viewed that way, they can each have their own query.
答案是一个问题：“我的视图非规范化了吗？我可以预先计算更多吗？我可以更好地表示这些信息，从而减少需要的查询吗？”
争取“1次查看==1次查询”。正如 qstarin 所说，查看！=屏幕。
The answer is a question: "Have I denormalized my views enough? Could I have precalculated more? Could I represent this information better so lesser queries are required?"
Strive for " 1 view == 1 query ". And as stated by qstarin, view != screen.
在我使用过的场景中，我们使用视图缓存作为我们希望渲染的对象的预先计算的视图。即使事件（我们使用 EDA）来自不同的域，我们也有维护视图缓存的处理程序，以便我们能够以适合复合 UI 的状态呈现我们希望的信息。我们努力的目标是让“select *”或“select * where ID =”成为针对视图缓存的唯一查询形式。有些页面有多个正在呈现的 DTO，但我们不必加入它们。如果我们觉得需要加入，我们会在预计算阶段执行此操作，当时我们正在处理包含我们希望存储在视图缓存中的信息的消息。
In the scenarios that I have worked with, we use a view cache to be a pre-calculated view of the object we wish to render. Even if the events (we're using EDA) come from different domains, we have handlers that maintain the view caches so that we can have the information we wish to render in a state appropriate for the composite UI. The goal we strive for is to have "select *" or "select * where ID =" be the only form of query against a view cache. Some pages have multiple DTOs being rendered, but we don't have to join on them. If we feel the need to join, we do that at the pre-calculation stage when we're handling the messages that contain the information we wish to store in the view cache.
您可以使用非规范化来避免这种情况。您应该使所有复杂的数据成为平面视图（无连接）。
另请参阅第一范式（1NF 或最小形式）。
在 CQRS 中，它用于使读取端尽可能快速和简单。因此，它可以水平缩放。
You can avoid this using Denormalization. You should make all your sophisticated data to be a flat views (no joins).
Also look at 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.