These days, web site design is all about frameworks and it’s difficult to ignore the fact that many of the most popular web frameworks implement some sort of an MVC or Model View Controller website architecture. The purpose of this blog post is to explain, why MVC is such a good fit for the web, including intranets, and why it is a good idea, no matter the platform you are developing on, to spend some time researching MVC frameworks before starting development.
In order to answer this question, we need to look back to the beginning of the millennium and understand how websites used to be designed. In the old days, previous to the proliferation of MVC frameworks, the web was a much simpler place. Many websites were primarily static or only interacted with the user in a simplistic way. Generally, these websites were implemented with the assistance of some sort of server-side scripting language such as asp or cgi. When a request for a page was made by the browser, it was the job of the server page to fetch data from a database, run some business logic and then combine the result with HTML to produce output that the browser could understand.
For simple applications this approach works fine, but as the complexity of web applications grew so did they amount of code contained within each of these server-side pages due to the complex logic necessary for a rich web application. The end result was messy code that was difficult to expand or maintain; software developers often refer to code written in this manner as “spaghetti.”
The first question that needs to be asked is: “What is a Model View Controller web architecture and what problems does it solve?”
The simple answer is that it is an object oriented way of organizing an application that enforces the separation of the code needed to render web pages from the code needed to implement business logic. This supports one of the fundamental principles behind good software design, “separation of concerns”, which directs that logical units of functionality should be separate from each other in order to help reduce complexity and to avoid the creation of “spaghetti” code. Essentially, what this means is that when developing an application, developers should carefully organize their code in such a way that different responsibilities are separated from one another so that the code remains “clean” and easy to understand.
The idea behind MVC website architecture is splitting up responsibilities, rather than assigning a single server page with the responsibility of fetching data, formatting it and displaying it. The MVC web architecture can be illustrated as follows:
In the MVC model illustrated above, each web request is forwarded to a controller object which acts sort of like a traffic cop. It is the controllers job to decide how each request should be handled. If the request is to update some data, the controller will contact the model and forward it the new data, asking it to update itself. Then it will return an appropriate view so the user is given a visual confirmation of what happened. If no data needs to be updated, the controller will skip contacting the model, select an appropriate view, and return it.
In many ways the model is the heart of the MVC website architecture. It contains a collection of objects that describe the data needed for the application to work. It also contains any required business logic for manipulating that data as well as access to another layer of code that can be used to persist data to a database. This persistence layer normally sits outside of the MVC model but only the model should have direct access to it because it is the responsibility of the model to manage the application’s data.
The idea behind MVC is rather than assigning a single server page with the responsibility of fetching data, formatting it and displaying it, that these responsibilities should be split up into models and views with a controller in between.
In an MVC website architecture, it is the responsibility of the view to provide an interface between the application and the user. Views know how to take data from the model and display it in a user friendly way. They can also provide the user with an interface to input data into the application.
So how does all this fit together into a real world web application, such as an intranet? Let’s look at a very simple example to get a better idea how the three components of an MVC web architecture fit together. A simple web application might be put in place to allow a company to manage a database of its employees. This web application might include four views that would allow the user to perform the following actions:
From the user’s perspective, they would begin by using a web browser to access a URL that will return the view listing all employees. Underneath the hood, this request is received by a controller, which first recognizes that no model needs to be updated, and second determines the appropriate view to return. Next, it forwards the request to a view which contacts the model and asks it to retrieve a list of employees. Finally, the view combines the list of employees with some HTML to produce a valid web page which is returned to the browser by the controller.
The other three actions are handled similarly by the controller except, prior to forwarding the request to the controller, it contracts the model and asks it to update, insert or delete employee data, as appropriate. After this is complete, the view of employees can be returned and it will now reflect any changes that were made.
I hope this blog post has helped to explain why MVC web architectures provide an important base for all web design. There are now many variants of MVC website architectures and a plethora of frameworks that implement them. Depending on your platform, it might be worthwhile to have a look at one of the following popular frameworks:
Conclusively, in the humble opinion of this software architect and developer, yes, MVC website architecture is good for all web applications, including intranets.