Interfaces and abstract classes for model classes (MVVM)

Question

According to what I've seen in school Model classes should only contain data members/properties and no methods/behaviour. However, while designing my UML class diagram I'm seeing possible interfaces and abstract classes for my Model classes. So my question is:

• if MVVM does advise against methods in Model classes, is it a good idea to design abstract classes/interfaces for Models? The way I'm seeing it is that in this way one can never benefit from the advantages of having interfaces and abstract classes for Models if you can't have methods in them.

Answer 1

In the model-view-viewmodel design, most of the domain specific logic and behaviour actually ends up in the model. This is called the domain model in domain-driven-design.

That domain code might be reused in several deployment units/applications/services in your business, so they are independent of the actual WPF application you are writing.

The viewmodel serves as the testable application-specific adapter and mediator for the view you are just writing so that

• the domain is not polluted with behaviour that is not needed across all applications
• the domain is not polluted with state (fields, properties) that are just relevant for the given screen or UI (presentation state)
• the view does not contain behaviour that you want to unit-test