Model-View-Controller, or MVC for short, is one of the oldest and most successfully reused software design patterns. It was first introduced with the Smalltalk programming language in the 1970s. MVC defines the overall architecture of the Cocoa frameworks. It’s a high level pattern for organizing large groups of cooperating objects into distinct subsystems: the Model, the View, and the Controller.
To understand the roles that subsystems play in the MVC pattern, it’s useful to analyze the capabilities and behavior of common applications. Most applications store information, retrieve information, present information to a user, and enable a user to edit or otherwise manipulate the information. In an object oriented application, information isn’t just bytes; objects encapsulate information along with methods for using the information.
The Model subsystem is composed of the objects that provide the unique capabilities and information storage for an application. Models contain all of the rules for processing application data. The Model is the key subsystem that makes an application valuable. It’s critically important that the Model subsystem is able to stand alone without dependencies on either the View or Controller subsystems.
The View subsystem presents information gathered from the Model and provides a way for users to interact with information. The key to understanding Views is to recognize that there are invariably a multitude of Views. For example, there may be a graphical user interface View, a printed report View, a command line View, a Web based View, and a scripting language View that all interact with the same Model.
The purpose of the Controller is to decouple the Model from the Views. User interaction with a View results in requests made to the Controller subsystem which in turn may request changes to information in the Model. The Controller also handles data translation and formatting for presentation to a user. For example, a Model may store data in Meters, but based on a user’s preference, the Controller may convert the data to Feet. A Model may store objects in an unordered collection, but the Controller may sort the objects before providing them to a View for presentation to a user.
The primary purpose of MVC is to decouple the Model subsystem from the Views so that each can change independently. The Controller subsystem enables that decoupling. You might be tempted to neglect the Controller subsystem because it’s often tricky to design and seems like it adds needless complexity. After all, the flow of information is between the Model and the Views, so why introduce another layer? The answer is that Views tend to change much more often than Models. Not only are there potentially many Views, but it’s the nature of user interfaces that they change based on customer feedback and evolving user interface standards. It’s also sometimes important to change the Model without affecting all of the Views. The Controller subsystem provides insulation between the Model and the Views.
Another consideration is that it’s usually easier to test a Model directly rather than through a user interface. When testing through a user interface, extra effort is required to determine whether a test failure is the result of a bug in the Model or a bug in the View or both. Furthermore, the Model is often developed by one team and the user interfaces are developed by another. The skills needed to develop the Model may be very different than those needed to
Applications that are editors or viewers for underlying information are naturally organized with the MVC pattern. MVC is applicable to applications that store information, retrieve information, present information to a user, and enable a user to edit or otherwise manipulate information.
Use the MVC pattern to group objects into separate Model, View, and Controller subsystems and decouple those subsystems within an application. By decoupling the subsystems, the Model and Views can each change without impacting the other making long term software maintenance and enhancement more productive.
Use MVC as an overall architecture to enable multiple Views of the same Model and support easy addition, removal, and change of Views.
Use MVC to promote reuse of both Models and Views. A Model can be reused with many Views, and just as importantly, a View can often be reused with different Models.
Use MVC to simplify simultaneous development of Models and Views by different programmers or different teams.
produce an excellent user experience.