Since August I’ve been helping Gastón I. Silva create a microsite about the MVC Family Tree. It is super cool, you should check it out. My angle is that I love Model View Controller, but I am annoyed at how polluted the definition has become. My former CSO, Martin Fowler, wrote a GUI Architectures article in 2006, but I arrogantly wanted to have another go at something pushing towards a definition.

Martin says in his article: “So don’t take my descriptions as authoritative”. The same applies to me - just another guy weighing in on the misunderstood Model View Controller thing.

Characteristics of MVC

As discussed with Gastón back in Auguest, before he got busy creating the above micro-site:

  1. Controller classically composes models and views. Either at a conceptual startup stage, or on a just in time basis for parts of the UI.
  2. Model changes can propagate to view w/o controller logic being invoked.
  3. View changes can propagate to model w/o controller logic being invoked.
  4. Controller can optionally mediate between Model and View
  5. View interactions often invoke controller logic for more complex situations (majority case of the above)
  6. Model is eminently discardable in order to abandon pending ‘changes’.
  7. Save of the model is often a deliberate action that propagates the models content to a permanent place (over services, or direct to some form of DB or store).
  8. Models can be nested or extended (Liskov style)
  9. Views can be extended, and are nearly always nested
  10. Unless the model is handed to a view, the view can’t access it. In fact the whole science of MVC screams injection in the dependency-injection style.

Java-ish example snippets

view = new ComboBox(new ComboBoxModel())

view = new MyExtendedComboBox(new ComboBoxModel(myStringArray))

view = new ComboBox(new MySpecialComboBoxModel())

view = new MyExtendedComboBox(new MySpecialComboBoxModel())

view = new ComboBox(new MySpecialComboBoxModel(new MyListOfThings()))

mscbm = new MySpecialComboBoxModel(new MyListOfThings())
view = new ComboBox(mscbm).withChangeHandler(someHandlerMethod(mscbm))

Why is this so hard to implement correctly?

Sometimes it’s the technology not the idiom

Non-instantiable views

Microsoft’s IIS (.Net 1.1 through 2) really wanted to be in the mix for web-request invocations. Code-behind was a thing for designed pages, which meant a couple of things:

  1. you were not going to be able to extend the view
  2. in unit testing situations you could not instantiate the view yourself, to inject in mocks of things that were not the view. Read Michael Feathers’ Humble Dialog paper.

With the web, and the increasing importance of JavaScript programming, it turned out that all code (even that for view markup/logic) is sprinkled around the DOM in a way that would require a PhD to understand. As such, it was hard to separate the Model View and Controller for the longest time. The open-source community had to evolve some techniques to do this. Even so, today’s poster-child for such technologies, AngularJS, only claims to be a Model-View-Whatever (MVW or MV*) application, and not an MVC application. Similarly, when the view is marked up in HTML, you’re going to have a hard time persuading people that it is extendable in a simple way.

Front controllers not an indicator

The “Model 2 Controller” ideas promoted by Sun in 1998, became associated with MVC, but it is a bit of a stretch really. Firstly, the model and view can’t casually update each other without a controller being the orchestrator of that (the two propagation critieria above).

Secondly, most implementations garbage collect the model between invocations, which although meeting the stateless goals of modern web development, seem to fly in the face of models being deliberately discarded only when “cancel” button being pressed, or after a “save” action has done it’s thing.

Late to the MVC party

In some cases the technologies makers had a good thing going that was counter to the MVC way. Microsoft, for example, had a huge amount of traction with data-binding. This perhaps started with MS-Access in the 90’s, and was very much in their DNA. I wrote some of the history of that for Gastón. This allowed them, in my opinion, to delay arrival in the land of MVC.

When I get CVs or resumes from candidates for developer positions, I sometimes encounter a pet peeve: MVC is a design pattern from 1998, and ASP.NET MVC is a Microsoft technology from 2008, but the two are conflated in print :(



blog comments powered by Disqus

Published

April 29th, 2015
Reads: