Interfaces and Abstract Classes for Model Classes (MVVM)
As per what I've seen in school, model classes should only contain data items / properties and methods / behavior. However, when designing my UML class diagram, I see possible interfaces and abstract classes for my model classes. So my question is:
- If MVVM does not recommend methods in model classes, is it advisable to develop abstract classes / interfaces for models? The way I see it is that this way you can never benefit from the benefits of having interfaces and abstract classes for models if you don't have methods in them.
+3
source to share
1 answer
In the model-view-viewmodel, most of the domain logic and behavior ends up specifically in the model. This is called the domain model in domain design.
This domain code can be reused across multiple deployment units / applications / services in your company, so they are independent of the actual WPF application you are writing.
The view model serves as a test adapter for the application and mediator for the view that you simply write to
- the domain is not polluted with behavior that is not required in all applications
- the domain is not polluted with state (fields, properties) that are only relevant to a given screen or user interface (view state)
- the view does not contain the behavior you want to unit-test
+2
source to share