However, the demand for websites that provide an application-like experience has meant that frameworks are stepping in to reduce the complexity and increase standardisation, allowing you to concentrate on the business logic and specifics of your application. Avoiding spaghetti code like I mentioned in Anti-Patterns: Do’s and Don’ts is one of a developer’s big aims as this results in a buggy and hard to maintain application. Gmail, Trello, Airbnb or Basecamp are examples of what would be considered a web application; while they also have native iOS and Android apps, the experience of using their websites is almost the same.
- Model-View-Controller (MVC)
- Model-View-Presenter (MVP)
- Model-View-ViewModel (MVVM)
I’ll go into MVC in a bit of detail in this post, and cover other frameworks at a later date.
While I’ve been learning about client-server systems since high school it’s worth describing what I mean in this case.
- Client – this is usually your browser but could also be an application on your phone or other device.
- Server – this is where the website or application and database are housed.
The example above is what would be typically referred to a thin client as the applications runs entirely on a server. These frameworks typically provide an entry point into the application via a series of requests or form inputs; for example, accessing a hyperlink like
would return the complete page for Product 1 to the browser and then suppose you wanted to edit it then you'd use
In this type of applications, the client (your browser) is doing very little and the server is doing all the work, including returning the full web page to the client. This is not a very efficient way to use a user interface and can be unresponsive. There have been improvements over the years to move some of the framework to the client. AJAX is an example of this, as it enables you to load information without reloading the whole page.
Suppose that on your product details page you want to dynamically load product reviews:
While you could go to a separate page with a list of reviews, it would be better if the reviews were just loaded into a container on the screen, without needing to reload the whole page. In ASP.NET MVC this is called a Partial View and it's usually a block of HTML rather than the HTML for a whole page. While this improves the performance, most of the application workload is still on the server.
Like most concepts of modern software development MVC originated in the 1970s. But it didn’t become a popular pattern until it was described in details in a book I’ve mentioned previously, the Gang of Four book. If you want to read more about the history of MVC, then Martin Fowler has done a great job.
The diagram below shows how the Model, View and Controller interact with each other.
Let’s take an example of searching for a list of products I’m interested in:
- The client tells the Controller to “Get list of Ultra-wide Monitors” by typing this into the search box and pressing the search button;
- The Controller updates the Model to get the list from the Database;
- The Model gets the list from the Database; typically this will mean interacting with the Data Access Layer or using a Service to return this data into the Model
- The Model may reformat or prepare the data so it’s ready for the view
- The Model updates the View with the list of Ultra-wide Monitors
- The View displays the list in a useful format such as showing which have been discounted, what ports the monitor has or if it’s even in stock.
The model represents and manages the data for an application. In a typical application the data will be stored in a database but it’s possible it could be using localStorage (for storing data locally in your browser) until the data is synchronised with a database.
At its simplest a model is a group of attributes; for a monitor this could be:
- Screen Size;
Or it could be metadata (data about the data) like:
- Measure (Kg, Stone, etc.);
- The data type, from example numeric or alphanumeric.
Although not always true, the model could also include validation logic, for example if the post code field is in a valid format.
In the context of a web page a view could be the whole or part of a page, for example a particular DOM Object which contains a list of products. Views are generally called ‘dumb’ as they don’t contain any logic; their main purpose is to render what the controller gives it and also to trigger calls to the controller.
Calls to the controller could be as simple as requesting an updated view or you could be editing some data and posting it to the controller to be validated and saved.
The basic idea of all these templating engines is the same: to combine a model’s attributes using placeholders and some logic to create the view that’s displayed to the user.
In MVC the controller is the glue that holds everything together: without it the Model and View wouldn’t know what to do with themselves. The controller has 2 main responsibilities:
- Receiving requests from the View;
- Updating the model.
Using the MVC pattern you'll end up with controllers that group certain functions. A few examples might be ProductController or maybe an OrderController. This type of framework is easier to extend, maintain and test applications.
Using MVC on the web typically means developing or using a framework that implements the MVC pattern. As you'd expect there are quite a lot of those; TodoMVC does a great job of showing off the main ones by showing the same Todo application implemented in the various frameworks.
Although not technically part of MVC, you should consider routing a supporting feature as it makes it much easier to test and to understand.
You’ve probably seen it before when you looked at the address bar in your browser and I’ve mentioned it in this article; when the page address looks like this:
then it’s likely using routing to go to the Search action of the Product Controller and passing in the search term ‘UltraWideMonitor’.
Fat Model, Skinny Controller
As shocking as that might sound taken out of context of course, we’re talking about the Model and Controller in MVC. What this means is you put all of your business logic into the Model so it’s easier to understand and troubleshoot, however that doesn’t mean you make your model so big that the opposite is true.
I haven’t really talked about ‘Separation of Concerns’ specifically but avoiding spaghetti code is a big part of MVC. While you can achieve this through good coding practices, MVC is a good way of enforcing this. It also has the following advantages over using no framework:
- Reduce duplication;
- Improves team working due to the separation.
MVC isn’t the only pattern for designing web applications but it has become one of the dominant ones. Stay tuned for Part 2 of this blog, where I’ll discuss MVP, MVVM, MVC and more.