An Introduction to Model-view-controller
The concept of Model-view-controller (or MVC) is a common one and has become increasingly popular as a design framework. However I’ve found that most introductions to the subject are very bland and abstract. In this post I’ll try to discuss some of the more practical reasons to go with MVC. Also while MVC can be used for many different kinds of application design, I’ll focus mostly on its use in web applications, since that’s where it’s use is most common at the moment.
In its most basic sense, MVC is just a clean way of organizing your code. In most web applications, you have a database containing multiple “business objects”, for example different products in an online store. Users can go to different pages in the application to view, update, or delete these “objects”, which are really just rows in a table most of the time. For any given query, the code in your application needs to be able to access the database, retrieve/update the relevant objects, and generate HTML code to be sent back to the browser.
As an example, imagine a simple user management system. People can login and view a list of users. Each user has a name, email address, and password. In addition, there are can be user groups, which are sets of users under a given name. A simple web interface for this system would be to have two listing pages, one of users and one for user groups. The user listing page would display a list of all users, and for each user there would be an “edit” link, that would bring you to a new page containing a form for the different user settings. There would also be a “delete” link to remove a user, and a “create” button as well. The user groups page would work the same way.
One way to implement an application like this would be for each page to have a corresponding file written in say, PHP. The page for listing users would connect to the database, get back all the users, and place the user information inside HTML that it would send back to the browser. Form submissions would be handled by getting the new settings from the form, and updating the database.
While the above system works, it has a number of disadvantages. For one, each file would need to directly execute SQL statements in the database. In the case of a change in schema, each file might potentially have to updated. Also, because the HTML code is intermixed with the rest of the business logic, changes to the interface could become complicated. In addition there would likely be a lot of code that would be duplicated when it comes to retrieving and manipulating objects.
Let’s look at how we could code this application with MVC. We’ll separate and consolidate all of the database code (the model), and all of the interface code (the view). All of the actual database interaction lies in the model, which produces a number of simple methods for manipulating objects. For any given page, there is controller, which gathers the appropriate objects and passes them off to views. The view is responsible for displaying the data in a user interface, is often 90% HTML/Javascript, with the rest being embedded code (like PHP or Perl) or a templating language (like JSTL).
There are many benefits to such a system. First, development can be simplified by allowing the designers to work on HTML and CSS code, and programmers to work on the backend model. These two pieces can be combined with small, simple controllers. Another benefit is in testing. The core of the application lies in the model, which can be tested programmatically dealing with any interface. Changing and updating the user interface is also made much easier.
In case we described above, MVC is used as way of organizing code. However, there are a number of frameworks that use MVC to make developing an application simpler. These include Spring for Java (which is now used by RSP Web as of version 2.1), Maypole for Perl, php.MVC for PHP, Rails for Ruby, and many more. These frameworks can make development even simpler, by including interfaces for base model objects, views (often with template languages), and controller classes.
