In an earlier post on a
MVC variant called VESPA I discussed separating out the the model and the controller into Store and Entities, Actions and Presenter respectively.
In a discussion on this approach the MVVM pattern was discussed and for me it helped with a problem I had with VESPA.
But first a recap of MVC before talking about MVVM.
The basics of MVC
The usual MVC definition (of which VESPA is a sub-definition) divides the application into three kinds of components, the model–view–controller design defines the interactions between them.
- A controller can send commands to the model to update the model's state (e.g., editing a document). It can also send commands to its associated view to change the view's presentation of the model (e.g., by scrolling through a document).
- A model notifies its associated views and controllers when there has been a change in its state. This notification allows the views to produce updated output, and the controllers to change the available set of commands. In some cases an MVC implementation might instead be "passive," so that other components must poll the model for updates rather than being notified.
- A view requests information from the model that it uses to generate an output representation to the user.
It is the View in VESPA that I have been having an intellectual problem with, which is where I think MVVM helps.
The basics of MVVM
Broadly speaking, the model-view-viewmodel pattern attempts to gain both the advantages of separation of functional development provided by
MVC as well as providing the advantage of abstracting data into the form that is recognisable to the end user.
The components of MVVM are as follows:
- Model exactly as MVC
- View exactly as MVC, the code that actually constructs the display, and contains the commands that create the application.
- View Model this is the binding between View and Model when the Model does not reflect the data that the users wish to see.
A criticism of the pattern comes from
MVVM creator John Gossman himself, who points out that the overhead in implementing MVVM is "overkill" for simple UI operations. He also states that for larger applications, generalizing the ViewModel becomes more difficult. Moreover, he illustrates that data binding in very large applications can result in considerable memory consumption.
I would agree and this has lead me to discount MVVM until this point.
This is because there is often a 1-1 mapping between data on the View and data in the Model. This is certainly true of
CRUD type screens.
The problem starts when users demand changes or the developers alter the model.
At this point the introduction of a view-model is needed.
My adaptation of MVVM to VESPA is to add a further subdivision to the View sooner than the Model.
I believe that the model-views are part of the View as they share the dynamism of the view code and should not be bundled into any projects or build components that belong to the model.
A good view-model object should appear to the View developer as just an other entity object.
How to define your Model-Views
If the Store objects bind and map to the physical data storage; and the Entities map to the logical structure that is the normalised data the application needs to hold.
The model-view maps to the concept and is an abstracts implementation details to focus on the entities and their relationships and properties that are elicited in the problem domain. It’s the ONLY part of the design best suited for communication with stakeholders in general.
So how to do the model-views ... just ask the stake holders what they want to see.
Then sit back and work out how to plug the entities into them.
The best part is you can mock the data in the model-view so the UX guys can work their magic but that is a different post.
