| • Science | • People | • Locations | • Timeline |
The Model-View-Controller is a design pattern in programming. It is most commonly thought of in the context of Graphical User Interface (GUI) construction.
The event-oriented nature of most modern GUIs is characterized by complex event handling. Each time the mouse moves, a button is clicked, or a key stroke is input, one or more events are generated. The code to handle these events at the lowest level is complex and difficult to write.
In contrast, objects in object oriented programming are composed of methods and data members that attempt to model something from the domain of interest. The best models are fully encapsulated, meaning that they implement every aspect of that real world object of interest to the domain of interest, and that they don't have any extra code that doesn't model the real world. Encapsulation also means that the class is implemented in such a way that the internal representation of data is not exposed to the user of the object.
The impedance mismatch between these two worlds, that of events, and that of objects, is something that's been recognized for a long time. Getting these two worlds to cooperate requires a lot of 'glue code' to make them work together.
The model-view-controller paradigm introduces the controller object in between the view (the GUI class) and the model (the object) to communicate between the other two objects. The actual implementation of the controller object can vary quite a bit, but the idea of an object to 'transform' events to changes in data and execution of methods is the essence of this pattern.
Attempting to stitch these two worlds together in a hand coded method without architecture is very common, and results in the model object being polluted with knowledge of the interface, and vice-versa. This makes the code very inflexible and difficult to maintain. For this reason (among other), many programming shops develop the user interface design early in the process of design, and freeze the interface early. The unfortunate side effect of this is that the domain of the problem often isn't clearly understood by the programmers until late in the implementation process. Thus, just at the time that the developers are finally competent to create a good interface, they are kept from changing it. MVC models allow the code to be more flexible later in the development process, allowing for changes that make sense at the time it makes sense to make them.
However, this paradigm also allows programs written in otherwise platform-specific languages, to be almost completely platform-independent. Since the model, which is the core of the program, does not have to interact with the interface in any way, the programmer is free to implement it in a cross-platform language such as C or C++. This makes it so the hardest part of porting the application is redesigning the interface for the new operating system. The platform-specific language (such as C# or Objective-C/ Cocoa) is only used for bridging the communication between the platform-specific interface, and the portable model. Theoretically, an application written entirely under the Cocoa framework for Macintosh could easily be ported to Windows under the .NET framework, as long as the model is written only in C++. All that would have to be done would be to redesign the interface in Visual Studio, and then to re-write the controller layer in C#, which is quite easy compared to the daunting task of rewriting the entire core of the program.
The first implementation of the model-view-controller to be widely known was introduced in the SmalltalkSmalltalk is a dynamically typed object oriented programming language designed at Xerox PARC by Alan Kay, Dan Ingalls, Ted Kaehler, Adele Goldberg, and others during the 1970s. The language was generally released as Smalltalk-80 and has been widely used s language in the early 1980s.