MVC architecture - structure, presentation, behaviour

Introduction

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.

MVC separates an application into its data model, user interface, and control logic. On the web these are more commonly termed structure, presentation, and behaviour; and in concrete form equate to XHTML, CSS, and Javascript respectively.

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?

Why separate?

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

Separating the structure (XHTML), presentation (CSS), and behaviour (Javascript) almost always results in smaller downloads: the presentation and behaviour do not need to be retrieved with each page, but can be cached by a browser. A usual side-effect of separation is that the XHTML markup becomes simpler, making pages smaller to serve to clients, thus faster.

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.

Maintainability Using standard markup, coding style, and identifiers make it easy to understand code long after it has been written. As Johansson says: 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.

Flow diagram

Figure 1: the relationship between model, view, and controller.

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.

In the introduction we linked the MVC pattern with the separation of structure, presentation, and behaviour. This is no coincidence: our three elements for separation have a one-to-one mapping to the three components of MVC. For a web page the XHTML structure is our model, the view is the CSS, and the controller is Javascript.

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">
  <head>
     <title>Whitepaper</title>
     <script src="behaviour.js" type="text/javascript"></script>
     <link href="view.css" rel="stylesheet" type="text/css" />
   </head>
   <body>
     <div id="personal-details">
     <h1>Personal details</h1>
     <dl>
       <dt>Name</dt>
       <dd class="String">Joe Bloggs</dd>
       <dt>Email address</dt>
       <dd class="String">joe@example.com</dd>
     </dl>
     </div>
  </body>
</html>


(Notice the XML prologue has been left out for clarity.)

We’ve used a dl element to list the definitions of the properties Name and Email address; a semantic addition is the String classes that tell us not only the type of the value but also acts as a handle for the controller (Javascript).

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.

Controller: the Javascript

We won’t delve into the guts of the Javascript here, but we will give an overview of what it does and why.

  • 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.

Summary

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.

References

Further reading

Technorati tags
;
;
; and
.

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.


www.mercurytide.co.uk would like to store information (cookies) on your computer. By continuing to use this site, you consent to this.
More info