Main Content

Why do we need a Model, View, Controller architecture?

Archive - Originally posted on "The Horse's Mouth" - 2012-02-25 09:46:06 - Graham Ellis

In the very early days of the web, it was a source of data - with files of marked up text (in HTML) being sent out to a browser program by a server running on a central computer. Requests to the central server were made in http (Hypertext transfer protocol), and the responses were translated by the browser program to come up with an appropriate screen display. And the fundamentals of this exchange, and of HTML, remain surprisingly little changed to this day.

"Can we include pictures please?" - just about the first update, and the browser makes requests for further data files - this time not text, but images in a format such as .gif or .jpg. And other add-in file type come later, such as Java Applets, Flash movies, downloads, JavaScript, and style sheets. That's still using http for transferring the data; it's simply a different type of data as far as the web server is concerned, and it's sent out with a header to tell the browser what it's getting, so that the browser can work out what do do with it.

"Can we send the output from a program, rather than a plain file from the server, please?". Scenario (one of ours). We can run an onsite course in the UK in any one of 127 different postcode areas. In any one of 32 counties in Ireland. In any one of 25 other countries in the EU ... and many other countries too. Onsite courses can last from 1 to 5 days, and can have any number of delegates up to 15. If there was an individual web page for each possible quotation, that would be over 10,000 separate web pages, so we can do that via a program which generates the HTML dynamically. The first way that such programs talked to the web server was through CGI (the Common Gateway Interface) as this allows established languages that predate the web to be used, taking inputs from (in essence) the keyboard, the command lin and environment variables which are, within CGI, taken over by the web server to feed in data that the user has entered onto a form.


"But I don't want to write a whole program - there are only a couple of things that change within a page!". It did seem rather messy to write a program to output what's mostly static text for applications like our quotation system. So in addition to CGI, many web servers support programming languages embedded within the HTML of the browser. I call this "HTML++" during our courses; it's the model used for languages such as PHP.


"I need to be able to chain together a series of pages for a user - to turn a simple form based program into a complete application". You can do so using CGI, or using HTML++. You'll need to remember which user is which, possible through hidden fields but much more commonly done using cookies. A cookie is a piece of data that's send out within an http response in addition to the regular content, and is then returned to the server with each subsequent request. In effect, the user is saying "it's me again". The programs on the server do need to manage the storage of data between form submissions by the same user, and to relink that data back to the continuing application. They also need to be able to manage sessions which the user has abandoned, and they need to be able to handling the echoing out of forms which weren't filled in correctly so that the user can make amends. Some of this is supported within the languages, or via optional add in modules, as it's such a common requirement.

"But my application is getting all confused and messy with all this stuff!!!". Yes - you can do so much with what I've described above, but the program elements really need some sort of structure to them to help ease the development, testing, use, maintenance and reuse. And that's where the "MVC" model comes in.

Please read on ... via my follow up Model, View, Controller article.