Now that we have our CRM app extended with a UI feature, it’s time to clean up and refactor the UI aspects into ViewModels so that the Model entity is left unimpeded by any UI concerns.
In the previous post our CRM domain Model entity grew by 75% in attributes for a single UI feature, so here we will attempt to shrink the entity back to it’s original size and illustrate how to implement the MVVM pattern using the MMV module.
In case you missed the first video, go watch Part 1 – Adding a feature to a basic CRM app and then come back here to watch part 2.
Side-note: If you received these posts via email, you might want to visit the blog since there are videos embedded here.
Benefits of MVVM in this example
As you’ll see throughout the video, the project is now layered into a CRM Model module and a CRM_Views View-Model Module, but in summary here are some design and runtime gains:
- Cleaner domain model
- Clear concerns
- Reduced domain model module (removed 10 Virtual/Calculated microflows with only 2 (1 per ViewModel) )
- Virtual/Calculated attributes are now stored, this give you
- Better performance as calculation occurs once upon save of the Model
- Makes previously calculated attributes searchable
- Multiple facets on a single entity can be developed in parallel since facets/aspects are isolated at the ViewModel level
In a future post we will show the other benefits we get in terms of security, validation and performance.
Watch how we refactor our Domain into a Model with 2 ViewModels: