Conceptually, there are several basic modules in almost any software. The model is a data container and the user interface (UI) is a way to communicate with the model. A relationship between the model and the UI is bidirectional. Data from the model is displayed to a user, and a user may change the model’s data. The model may keep some or all of the data in the main memory and store data in an external storage, such as files or databases (db). A relationship between the model and the data storage is also bidirectional. The UI has one or many views of data, which present data in a format useful to users, and one or many controllers, which channel changes in data to the model. For example, a web application, after a user request, retrieves data from a database and displays it in a presentable way. After the user changes the data, the application updates the database. There is a flow of data between the UI and the db. For a simple data model and a simple application, the view is often combined with the model. However, a coupling of those parts produces maintenance problems. One problem is that the UI tends to change more often than the model of the db. Another problem is that an application may have business rules that are more than simple data transmissions. It is important to organize a software application to allow for easy modifications of its parts. There are many design patterns that may help in detailing this software architecture. The most popular one, with a long history of different variations, is the Model View Controller (MVC) pattern.

MVC (http://en.wikipedia.org/wiki/Model-view-controller) is a design pattern that isolates an application’s data from the UI. In MVC, the Model represents data of the application and the business rules used to manipulate the data, the View corresponds to elements of the UI such as text fields, and the Controller manages details involving communication between the model and views.

There may be many views and only one controller or many views and many controllers. A view and its controller may be separate or combined together. A view might have its own model in addition to the model for all views. All those and other variations exist in different versions of MVC that even got some new names such as MVP (http://en.wikipedia.org/wiki/Model-view-presenter), MVVM (http://en.wikipedia.org/wiki/Model_View_ViewModel), MOVE (http://cirw.in/blog/time-to-move-on), and MDV (http://polymer-project.org/platform/template.html). There are also many articles about MVC and its variations (www.mvccentral.net, www.infoq.com/ASP-NET-MVC/articles/). Thus, for a learner, it is not easy to grasp the essence of MVC. The following sentences provide this in a nutshell (refer the MVC pattern figure): a user action triggers a UI event that changes the model’s data by invoking data actions in a controller. A view registers with the model to be informed about data changes. When a view is informed about the changes, it reacts by refreshing its display. Implementing this pattern makes our app obey the Separation of Concerns design principle (the code of views, controllers, and models are loosely coupled). Thus, the different layers in MVC can be developed independently from each other, so that the code is better maintainable. This is especially important for web applications, where the views are presented in the client’s browser, and the data source (which interacts with the model) sits on a server. The model and controller code can be executed on the server (as in traditional web applications) or on the client (as in RIA apps), or distributed.

The MVC pattern

It is important to note that the model does not depend on the controller and views. In other words, there are no references to the controller and views in the model (and that is the reason why a view registers with the model to be informed about changes in the data). However, the controller and views depend on the model. In this way, the model may be developed and tested without the views and controllers. In addition, new views of the model may be added easily. Even different applications may use the same model.