views:

169

answers:

1

Would I be correct in thinking that the 'Model' represented by the M in MVP could be a domain model or a presentation/view model?

+3  A: 

Yes, the Model could be essentially any Model. The way I see it, the original intention of MVC was that it is a Domain Object, and that is certainly still possible.

However, my experience have shown that a better fit is achieved if we introduce a specialized ViewModel/Presentation Model as a insulation between the Domain Model and the View.

Even when the ViewModel seems to be semantically identical to the Domain Object, such an insulation enables us to vary the two independently and thus follow the Single Responsibility Principle.

It often turns out that the View needs some logic that applies to the specific UI technology, and this logic fits badly in the Domain Model. Examples include

  • Logic that determines if a particular control should be enabled or disabled. Domain Models should know nothing about controls.
  • Logic that maps a state to a color. Colors are technology-specific - they are different CLR types across Windows Forms, WPF and ASP.NET.
  • Validation. Input forms normally allow input of invalid data without throwing exceptions. Instead, they provide feedback to the user that the data is invalid. Domain Objects, on the other hand, should protect their invariants, and thus throw on invalid input.

More information can be found here

Mark Seemann
Thanks for that great explanation. My intention was to have the controllers query the domain and a helper(some sort of mapper/assembler) build a presentation specific view model, would you agree that this approach is correct?
David
Yes, hit the Domain Model to retrieve whatever you need, use a Mapper to map to the ViewModel, and render the View using that ViewModel. That's essentially what I do as well.
Mark Seemann
Thanks again Mark. I have some other questions around this subject that I'm going to pose and would appreciate your input.
David