Model View Controller, it’s a simple concept, where the View is
simply the front-end representation of what you want to represent, such
as the template (or JSP, God forbid) for the web page you want to
But is it really that simple? Most web frameworks seem to assume it is, but I’m not entirely convinced.
Let me elaborate: Say you want to display a Widget, which you sensibly render at a HTTP GET URL of http://yourdomain/widgets/1, indicating you want to display the information of the Widget with ID 1.
In a typical web scenario using your browser, this would render not only the details of the Widget, but also a header, footer, navbar and various other pieces of information that you’d find in a base web page. In it’s purest sense, is this really relevant for a Widget View? I’d say that it’s not. We are interested in viewing the Widget, and possibly what we can do with said Widget if we adhere to HATEOAS principles.
In other words, in its purest sense we want a view of the Widget and possibly information about the various ways in which we can work with the widget. Everything else around it is effectively Layout Decoration, which could (should?) differ wildly depending on the client that is viewing the Widget: for instance, a full desktop browser might see a lot more layout decoration than a smartphone browser, whereas a client expecting a JSON response will see only a JSON representation of the model for the view.
Decomposing the View into Resource View & Layout
What I am suggesting here is decomposing the View into it’s two logical constituent parts given my rationale above (in the context of the Web):
- A Resource View is a client specific HTTP representation of the Resource/Model we want to View.
- A Layout is the client specific Decoration for the Resource View, containing common elements such as navbars, headers, footers, login prompts and whatnot.
Of course, most web frameworks already provide means of extracting common layout elements (though most of them do it rather poorly), but they rarely make much distinction between the two, nor do they give developers useful aid or “nudges” to make this distinction. In the language of most existing web frameworks, a View is a View which contains not only a rendered representation of the Model/Resource we are interested in but all the other things as well.
Decomposing the View is a Necessity for Multi Channel Delivery of Webapps
To summarize, I think the view (pun intended) that a View is simply a View is an approach that is too coarse grained to be suitable for the landscape of the modern web: duplicating effort by creating a browser experience, a mobile web experience, a tablet experience and a REST API is just not a feasible approach when time-to-market is of the essence, not to mention the wastage of money and resource in doing so. By consciously decomposing the View further as I have suggested, re-use can be much higher, re-work can be minimized and client specific layout decoration can easily be extracted, as can multiple Resource View Templates, as the scope of them are restricted to simply rendering a view for a specific resource in slightly different ways and nothing else.
I believe that View = Layout + Resource View is a necessity if you want to deliver a web experience to multiple channels/clients without running the risk of doing massive amounts of duplicate work and re-work.