MVC Website Architecture – Good for Intranets?

By Ryan Hall
May 23, 2013
6 min read
Blog
Intranet
Organize your internal communications

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.

A Brief MVC History Lesson

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 languages 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 the 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.”

What is MVC Website Architecture?

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:

MVC Controllers

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 controller’s 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 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.

MVC Models

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.

MVC Views

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.

A Simple MVC Website Architecture Example

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 of 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:

  1. List all the employees in the database.
  2. Update an employee record.
  3. Insert a new employee record.
  4. Remove an employee record.

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

Why is MVC Website Architecture Important?

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:

  1. Spring MVC for Java
  2. ASP.NET MVC for .NET
  3. Rails for Ruby
  4. Django for Python
  5. CFWheels for Coldfusion
  6. CodeIgniter for PHP

This list only scratches the surface of all the available options when it comes to MVC frameworks.  In fact, for many modern websites with rich, complex interfaces,  it is not uncommon to have both a server-side MVC framework, such as one of the above, as well as a client-side MVC framework like Backbone to organize JavaScript code.  One of the most important things to keep in mind when approaching a new web-based software project is to start with a good MVC framework as a base and then try to make good design decisions that are in step with that framework.  Choosing a good framework is crucial and is often difficult to change later on, so be sure to spend some time doing the necessary research to ensure the correct choice is made upfront. The end result will be an application that is both easy to maintain and easy to extend for new features.

In the humble opinion of this software architect and developer, MVC website architecture is good for all web applications, including intranets.

By Ryan Hall

Ryan Hall is a senior full-stack developer at IC Thrive. He is a software craftsman and leader with over 12 years of experience in the IT industry including more than 10 as a software engineer. Ryan is passionate about the development of high-quality software and helping teams to write efficient and maintainable code.