CQRS - Read Model DTO Confusion

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 开发者_如何学Pythonconstantly 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?

But I routinely work with some complex screens that would involve multiple selects for things like reference data in drop down lists, widgets, etc...

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.

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.

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.

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.