MVC architecture - structure, presentation, behaviour
Published 16th December 2005
When the web was in its youth (or at least, more youthful than it is today) people would throw up individual pages here and there with little consideration of accessibility, maintainability, or consistency. As the focus turned from pages towards sites developers recognised a need for software architectures. Perhaps linked to the current acceptance of object-orientated programming as de rigueur, the model-view-controller (MVC) architecture has become the most popular.
This paper concerns itself with discussing the MVC architecture and outlining the advantages of keeping these three components entirely separate before moving on to showing the architecture in action. An understanding of object-orientated programming is assumed; for those as-yet untutored readers, a short introduction can be found in What is an object?
You only need spend a short time reading web-design publications like A List Apart, Stylegala, and Digital Web, or blogs and forums, before realising there is an assumption that separation of structure, presentation, and behaviour (talk of the first two being most common) is the Right Way To Do Things™. So why should you separate?
Among the many advantages (recently written about in Roger Johansson’s Ten reasons to learn and use web standards) we find these the most compelling:
Reducing bandwidth usage
In Throwing tables out the window, Doug Bowman of Stopdesign experimented in separating the structure, presentation, and behaviour of Microsoft’s website: Bowman reduced the size by sixty-two per cent and estimated a 329 terabyte saving in bandwidth.
Meaning and accessibility
Remove presentation and behaviour from the structure, and you are left with only semantically-correct markup and data. The semantics can be used by screen-readers, text-only browsers, mobile devices, next-generation search engines, and microformat discovery programs to garner meaning.
Would you rather wade through many kilobytes of multiply nested-tables and spacer-images or just browse through a clean and well-structured document when you need to update your site?
We’ve seen why it should be done; let’s move on to the theory behind separation.
The model-view-controller architecture
Model-view-controller (MVC) is a popular object-orientated programming pattern used for years in all kinds of application development, and is found as the basis of web-application frameworks such as Apache Struts, Ruby on Rails, and the aborning Symfony. Using the MVC pattern means we can detach the business objects from business logic and data presentation.
The model is the data structure, the representation of the information for the application; it is reusable in any application. For example, in an airline seat-booking system the object representing a flight should be available to call-centre applications, online-booking systems, and check-in software.
The view presents the model in a form suitable for display and interaction. In our example booking system the view would be the user-interface. Each different application would have its own user-interface, and hence its own view.
The controller maps to the behaviour of an application, responding to events such as key-presses and mouse-movement by making changes to the model and the view.
Note that the model has no direct knowledge of the view or the controller; this is where the separation is most obvious. The relationship between the three components are shown in figure 1. Assuming that the model and controller are logically correct the only component that should ever need to change is the view.
Now we’ve made the argument for separation and seen how it works in theory, let’s put it into practice.
MVC in action
As an example of how to achieve full separation we will design a common component of Web 2.0 applications: as seen on Flickr and almost everything by 37signals, the popular and ingeniously named “text that you can edit when you click it“. If you’re too excited, you can view the example before you read on.
Model: the semantic XHTML
Our XHTML is semantic, smart, and ready for its first day at school — it doesn’t get much simpler.
<html xmlns="http://www.w3.org/1999/xhtml" xml:lang="en-GB">
<link href="view.css" rel="stylesheet" type="text/css" />
<dd class="String">Joe Bloggs</dd>
(Notice the XML prologue has been left out for clarity.)
View: the CSS
The presentation is important because we need to inform the user that they can click the name and email address to edit them — to borrow some Java terminology, we need to inform them that the value is in a mutate mode and not a observe mode.
Flickr indicates something is editable by adding a light-yellow background when the mouse hovers over it, while products from 37signals augment the Flickr technique with a small ‘edit’ link to the left side (which toggles the mutator). We’ve employed a similar technique: the properties have a yellow background when hovered over, and show a small image to the right when in a mutate mode.
- Registers onclick events for all dd elements with the class String.
- Acts on clicks on such elements (we’ll call them observers), calling the edit() function.
- Defines the edit() function to: create a new input element (the mutators) with the value of the observer (its first child node); appends this input as a child of the observer; and unregisters the onclick event of the observer.
- Adds a listener to the new mutator for its onkeypress event, which calls the save() function to recreate the observer with its new value, registers a listener to the onclick event, and removes the mutators.
This may seem like a lot of work, but we have complete separation of the structure, presentation, and behaviour. And think about the benefits: how easy it would be to add more editable properties to the page; how easy it would be to change the presentation of the page; how you could edit the behaviour without touching the structure or presentation; how someone could understand what was happening without seeing the page in action. And remember that your code will be neater, smarter, and more attractive to your peers!
You can see the example in action. Keep in mind this is only a prototype and we do not pretend it is free of usability issues — it is left to the interested reader to remedy this.
We were able to achieve complete separation of structure, presentation, and behaviour by applying the common MVC design pattern. Although this application may require a high initial outlay in time, the benefits are many: reducing bandwidth usage, allowing for more semantic structure, better accessibility, greater site consistency, and easier maintenance.
Mercurytide is a forward thinking, dynamic, and innovative Internet applications development company. We are well-established with a proven track-record within the industry of attracting blue chip clients from around the world. We produce regular white papers on a variety of technology-orientated topics. For more details see the Mercurytide website.