MVC - model-view-controller

The model-view-controller (MVC) design pattern - MVC introduction

In theory this sounds great, but I've found in practice it takes some getting used to. Admittedly, it might take longer for me cause I'm a (reforming?) guerrilla programmer (the error in my ways has caught up with me and I'm taking steps towards programming for people - not computers). Sure, I've found that the design patterns are useful, but their advantage is not only in creating re-usable, easy to understand code - but, more importantly in helping me clarify the way that I think about programs. I find this second advantage much more substantial.

Writing code is usually the easy part - the hard part is figuring out exactly what code to write. Time spent carefully thinking about the code to write will save enormous amounts of time and effort when it comes to actually writing the code. Still, many people don't always work that way - myself included. Design patterns are helping me shape the way I parse a problem, which leads to helping me break up the problem into objects and modules. The Model View Controller pattern has probably changed my style and efficiency the most. It has lead to new ways of writing entire applications, constantly improving my applications in usability. Yet, while I was learning about the pattern, I was surprised at how hard it was to find information about it

So, I decided to add a couple of pages about the pattern myself. I want to share some info about the pattern that I've found so useful but seems to get so little press. And I figured it would also clarify it even more in my own head. One little disclaimer - you might notice differences between what I present and what others present. The differences are representative of our styles I suppose - because I've made adjustments along the way and have changed things. I've tried to mention these areas when they pop up.

The MVC pattern is surprisingly simple, yet incredibly useful. Essentially, the pattern forces one to think of the application in terms of these three modules -

• Model : The core of the application. This maintains the state and data that the application represents. When significant changes occur in the model, it updates all of its views
• Controller : The user interface presented to the user to manipulate the application.
• View : The user interface which displays information about the model to the user. Any object that needs information about the model needs to be a registered view with the model.

MVC advantages

Just by breaking the program down into the three MVC components, one gains many advantages. These are the most significant ones I've found through my own experience:

• Clarity of design : the public methods in the model stand as an API for all the commands available to manipulate its data and state. By glancing at the model's public method list, it should be easy to understand how to control the model's behavior. When designing the application, this trait makes the entire program easier to implement and maintain.
• Efficient modularity of the design allows any of the components to be swapped in and out as the user or programmer desires - even the model! Changes to one aspect of the program aren't coupled to other aspects, eliminating many nasty debugging situations. Also, development of the various components can progress in parallel, once the interface between the components is clearly defined.
• Multiple views : the application can display the state of the model in a variety of ways, and create/design them in a scalable, modular way. This comes up in games, with a cockpit and a radar view, and in my research applications, where I have a view to display the state of the model and another view that collects data, calculates statistics, then to saves the data to disk. Both views are using the same data, they just use the information differently. During the development process, I usually start out with a text based view, which just prints out the data that the model is generating. Later, as I create new views, I can use the text based view to verify the performance of the new views.
• Ease of growth : controllers and views can grow as the model grows; and older versions of the views and controllers can still be used as long as a common interface is maintained (the text view just mentioned is an example). For instance, if an application needs two types of users, regular and administrator, they could use the same model, but just have different controller and view implementations. This is related to the similarity with the client/server architecture - where the new views and servers are analogous to the clients.
• Distributable : with a couple of proxies  one can easily distribute any MVC application by only altering the startup method of the application. Now, the application becomes a full fledged set of client and server applications.
• Powerful user interfaces : using the model's API, the user interface can combine the method calls when presenting commands to the user. Macros can be seen as a series of "standard" commands sent to the model, all triggered by a single user action. This allows the program to present the user with a cleaner, friendlier interface.