My thoughts on the View Data Model pattern for ASP.NET MVC
In almost every scenario only a small number of UI elements can be directly bound to the Model, especially if the developer has very little or no control at all over the Model itself. In many cases, I have observed that the Model will have data types that are incompatible with the View and the Model data must be synthesized or “massaged” before it can be consumed directly by the View. In order to compensate for this, the UI may have to perform complex operations that are in the purest terms, inappropriate actions for a UI layer. These operations may be too “View Specific” for the Model and at the same time too “Model Specific” for the View.
The View Model pattern provides a bridge between the Model and the View, it is actually intended to provide a “Model of the View”. The View Model provides a “View specific” Model that can be used directly by the View, it can perform data-transformations which enable direct data binding by the View’s controls and it can provide commands that the View can use to interact directly with the Model. I always think of a View Model as a View-Centric interface to the Model which provides View-Centric interaction with the Model.
In my last project for example, we wanted to bind directly to dropdown boxes. Our architecture required that our models return entities that were much too complex for direct binding to the Views and we had some business specific policies (inappropriate logic for the UI layer) that had to be enforced for specific user types and program types which was much too complex for the Controller Actions. If this wasn’t complex enough already for the UI, , our architecture also required that our policies be enforced on the Web Server.
To solve this problem, we created a View Data Model in the Web Application Layer which contained our policy logic and which “massaged” the model data in a way that allowed our controller code to be very small and enabled direct binding to our data types by our Views. This also provided a bit of re-use, but keep in mind that at the time this was a new feature in ASP.NET MVC and there wasn’t a whole lot of information about the pattern.
Evolution in our world is very rapid, like fruit flies and Today, just a month or two later there are plenty of examples and best practices that we can reference as we continue to implement this great pattern moving forward and if we think about it up front, will provide a lot of good re-use. Our first implementation was not perfect and if you want to learn more, I would suggest that you choose from among the many examples that now exist to evolve the ideas even further.