Domain Model vs View Model

Question

I'm in the early stages of my programming career and I've been working with MVC for just about a year now. I've spent much time learning about the pattern and the concepts behind it, but as the projects I'm working with get larger I'm starting to think that maybe I don't have the best understanding of how the model layer is supposed to work.

I hear a lot about always having a View Model to protect your Domain Model but how does this work in practice? What does the relationship between the two look like? What if a model doesn't need any extra "view" logic, should I just create a copy of it? Why?

Answer 1

You asked exactly the right question: "Why?"

MVC, MVP, MVVM, and probably a thousand minor deviations of those... There are so many design patterns out there, and the differences are very subtle. The only way to get clear grasp of how to design the GUI layer of your application is probably to lean back, collect your requirements and weigh them against each other. For example,

• Do you need automated GUI tests? To what extent?
• Do your screens include "complex" behavior that isn't easily covered by data binding? How many?
• Do you need to be platform-independent?
• What components will you likely want to reuse? For example, does your application target vastly different screen sizes but you want to reuse the business logic for all of them?

Example:

If you know you're not going to run automated tests and you only target the Swing platform (i.e. PCs with a relatively narrow range of screen resolutions), don't bother splitting your code in three classes and creating a Swing-independent view model. You gain nothing from it.

On the other hand, if you develop a GWT application that requires automatic tests because you have non-trivial business logic, you'll likely leverage the loose coupling MVP provides you so that you can run your tests in a lightweight fashion (i.e., without GWT components in a pure Java environment).

It's all about the specific requirements of your application and technology stack... And that is probably the reason why there are so many reincarnations of the same pattern.

Answer 2

A rather general answer. Traditionally the View in MVC would request the information it needs from the Model, and the Model knows nothing about the View. Data binding (very popular in Microsoft UIs) ties the View quite closely to the underlying Model, which conflicts with the traditional MVC.

So the solution is to have one model for the view to bind to and a different model which really is the Model. These are the View Model and Domain Model.

To your questions: The relationship between them is that the VM knows about the DM, not vice versa, and the VM has extra stuff in it specifically for the View to use. If you don't have a View with these requirements, you don't need a View Model at all.

In those cases where a VM is needed, I would recommend thinking of it as a wrapper over the DM. The VM will have properties unique to view, and will delegate requests for and updates to business data to the DM. There should be no duplication of logic between them.

When I've used this in WPF or Store apps the VM is the data binding context for the view, in close proximity, and the DM accessed through a formal interface, possibly far away.

I have no idea if there is a pattern for this -- my mind doesn't work that way.