Right now, working on getting it into a codeplex project, hopefully soon.

Short answer: yes we have a strategy for bringing multiple entities together.

Honestly, 95% of the time, if the models are shown on one screen, they likely have a relationship built in already. If not, we take a hard look at putting it in.

If there are multiple disparate entities in one screen, we look at several things:

- Is each entity related to one section, a widget, that should be made into a partial/subcontroller/partial request/RenderAction call? If so, we break it out that way
- If not, create a component that combines all the models. This component likely has some concept in the ubiquitous language, so we often put that component type in our domain.

Before we had a good mapping strategy, I would have agreed. Testing manual mapping code is tedious to the point of hair-pulling. Definitely not every model needs this strategy. But when we put it in, we were quite surprised how much the presentation technology influenced our designs. For the projects where domain model is not 1:1 with screens, this strategy definitely helps.

Two things strike me:

In my experience, a View model that completely hides the Domain model will cause a lot of duplicate code. To me this means you have to have a good strategy for “auto mapping”. Without it there is just way too much overhead. This is a topic you mention but do not go into details with. Some details here would be highly appreciated.

Is your approach (including your “auto mapping” strategy) based on a 1:1 mapping between domain model and presentation model? My experience with this is that the presentation model will sometimes contain information from several domain models. What is your take on this problem?

- Tore Vestues

In my personal projects I use the model directly up to the view and grass is alot greener!

great post Really insightful.

Would be really nice to get some pointers on your “automapping” stuff, do you use code-gen or some expression tree thing? Would love a blog post on the general concept. Been thinking about that lately.

- Rasmus.

I’m not sure thats any clearer, but I think the important thing is to use two separate models, name them as you see fit, and then use those names consistently.

Nope, that’s _exactly_ what we’re doing. Except we call them “DTO” and “…” … FormModel? One is optimized for displaying, and one is optimized for capturing. Because we’re using auto-mapping from our Domain Model to both of these guys (for edit scenarios, for example), we don’t have to do that boring mapping code.

And exactly how you have your scenario, each xTO carries _exactly_ what is needed, and no more.

It certainly seems like overkill in the first instance but is quite manageable with a robust mapping infrastructure. On the project I was working on our biggest problem was not having clear conversations about what was responsible for what. To fix that I created the language of VTO (view transfer object – takes information to the view) and DTO (domain transfer object – takes information towards the domain).

I know this is ‘SRP to the max’ but it has some definite benefits particularly around testability and also in terms of functionality. In the date time example discussed earlier the VTO would carry information to the screen as a string pre-formatted for display according to any presentation rules you may have for date time values. Then after the post action the controller accepts a DTO as its only parameter (leveraging custom binders) where the value is parsed and carried as a DateTime value.

I would be interested to hear others thoughts.