The Principles of the MVC Design Pattern
The MVC paradigm is a way of breaking an application, or even just a piece of an application’s interface, into three parts: the model, the view, and the controller. MVC was originally developed to map the traditional input, processing, and output roles into the GUI realm:
Input –> Processing –> Output .
Controller –> Model –> View
A model is an object representing data or even activity (e.g., a database table or even some plant-floor production-machine process).
The model manages the behavior and the data of the application domain, responds to requests for information about its state, and responds to instructions to change its state.
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.
- The model is the piece that represents the state and the low-level behavior of the component. It manages the state and conducts all transformations on that state. The model has no specific knowledge of either its controllers or its views. The view is the piece that manages the visual display of the state represented by the model. A model can have more than one view.
Note: the model may not necessarily have a persistent data store (database), but if it does, it may access it through a separate Data Access Object (DAO).
- A view is some form of visualization of the state of the model.
- The view manages the graphical and/or textual output to the portion of the bitmapped display that is allocated to its application. Instead of a bitmapped display, the view may generate HTML or PDF output.
- The view renders the contents of a model. It accesses enterprise data through the model and specifies how that data should be presented.
- The view is responsible for mapping graphics onto a device. A view typically has a one-to-one correspondence with a display surface and knows how to render to it. A view attaches to a model and renders its contents to the display surface.
- Controller facilities change the state of the model. The controller interprets the mouse and the keyboard inputs from the user, commanding the model and/or the view to change as appropriate.
- A controller is the means by which the user interacts with the application. A controller accepts input from the user and instructs the model and view to perform actions based on that input. In effect, the controller is responsible for mapping end-user action to application response.
- 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 HTTP, GET, and POST 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.
- The controller is the piece that manages user interaction with the model. It provides the mechanism by which changes are made to the state of the model.
- Effective implementation of OOP concepts using classes and methods.
- When there is excessive traffic, the server will not be down because of MVC architecture with a browser caching feature.
- Information will not be passed through IDs. Information will be posted and passed through encrypted format.
- Enhancement and maintenance is less time consuming.
Milind Madane currently works with the MRCC Netvidya development team. This team is working on the following products using the MVC architecture:
Netvidya 7 Steps, Netvidya CACPT