The Model View Controller, or MVC for short, is a software architecture pattern which solves an age old problem of separating data access and business logic, the data itself and the User Interface (UI.) In the MVC, the UI is the View, the data itself is the Model, and the intermediate component that separates business logic and data access from the View and Model is called the Controller. This architecture pattern is not new, however. It was first introduced in 1979 by Trygve Reenskaug while working on Smalltalk at Xerox labs. His original work was titled Applications Programming in Smalltalk-80(TM):How to use Model-View-Controller. It seems that today the rage in building new large scale websites and web-based applications has centered itself around the MVC architecture.
We can define the MVC as follows:
- Model -The domain-specific representation of the information that the application operates. Domain logic adds meaning to raw data.
- Many applications use a persistent storage mechanism (such as a database) to store data. MVC does not specifically mention the data access layer because it is understood to be underneath or encapsulated by the Model.
- View - Renders the model into a form suitable for interaction, typically a UI element. Multiple views can exist for a single model for different purposes.
- Controller - Processes and responds to events, typically user actions, and may invoke changes on the model.
Taking our definition of the MVC components from above, we add some more detail to the components:
- Model - The model represents enterprise data and the business rules that govern access to and updates of this data. Often the model serves as a software approximation to a real-world process, so simple real-world modeling techniques apply when defining the model.
- View -The view renders the contents of a model. It accesses enterprise data through the model and specifies how that data should be presented. It is the view's responsibility to maintain consistency in its presentation when the model changes. This can be achieved by using a push model, where the view registers itself with the model for change notifications, or a pull model, where the view is responsible for calling the model when it needs to retrieve the most current data.
- Controller - The controller translates interactions with the view into actions to be performed by the model. In a stand-alone GUI client, user interactions could be button clicks or menu selections, whereas in a Web application, they appear as GET and POST HTTP requests. The actions performed by the model include activating business processes or changing the state of the model. Based on the user interactions and the outcome of the model actions, the controller responds by selecting an appropriate view.
As you can see, the MVC architecture is very powerful and truly scalable. When put into the context of large web sites and web-based applications, it really shines. Many different scripting languages and frameworks are now taking advantage of MVC architecture. Two of my favorite are Ruby on Rails and Cake PHP. I hope this introduction to MVC architecture helps people who are currently involved (or will be involved) in large projects that will build applications on top of the MVC architecture. As always, I am happy to discuss my posts in more detail via email.