Mark Eschbach

Software Developer && System Analyst

Model View Controller

The Model-View-Controller, commonly referred to as MVC, is an architectual style derrived in the original Smalltalk days. Originally distilled out of the need to build reasonably complex GUI applications on a single node within an object oriented system, the architecture uses core object-oriented patterns such as composition and observers. As MVC is an abstract architecture, I will discuss each component as a class, however in practice multiple classes may take the place of each component.

Controllers are the core interpreters incoming events, such as user events from the views or from a remote system. For each event the controller will apply a specific state change (including not state change) upon the model. When the model is updated an event is dispatched to notify the view of a change, effecting the changes. An example would be an audio system with a volume display. A controller would consume an audio up event, modifying the model to represent the previous volume plus one. An event would be dispatched to both volume display and the audio rendering component. The volume display component would now display the new volume, possibly by querying the model for the current volume. The audio rendering component would increase the actual amplitude of the sound being produced by the speakers.

Despite it's widespread popularity, MVC has many different meanings and has morphed over the years. Traditional GUI MVC systems required the controller to feed events off of view components for user input, while fat service tiers for web applications require entire roundtrips to handle user input. With the rise of the web frameworks, many have tried (some even succesfully!) to create an MVC framework; however there are many benefits and drawbacks to this approach. In my opinion based on expierence MVC works great within the UI tier (read browser or client), however breaks down when you require IPC to other processes.