Whenever you write a piece of code, there is usually some dependency amongst various modules in one form or the other. Any change in some part of the code would require changes somewhere else. This is where the idea of MVC came from. MVC is an architectural design pattern that is used to develop Web Applications. It mainly focuses on separation of concerns and delegation of duties by separating application logic into three parts, namely, Model, View and Controller which makes applications flexible and easy to maintain.
The dotted arrow from model to view shows that it indirectly updates the view. Once the response for a user query is generated by the Model, the View has to be updated. The View is updated by the Controller.
Let us discuss the architecture in detail.
MODEL – This is what we call the “brain” of the system. Model doesn’t know anything about views and controllers. When a model changes, typically it will notify its observers that a change has occurred. It is basically loads and manages data of an application, including other things like validations over that data.
VIEW – The View specifies what is to be displayed, that is, the user interface. It is essentially the “presentation” layer of MVC that decides the layout and representation. It should be informed about the existence of model but is not involved in direct communication with it. Also, it highlights certain attributes while suppressing others.
CONTROLLER – I handles all the communication between a user, view and the model. The controller receives the actions on the view for example submit action over some form to save some data and depending on these actions if some changes are to be reflected on the view are done by the controller by passing the appropriate validated data from the model to the view.
Just to add more clarity to the scenario, let us consider a simple example.
Let there be a user who performs an action, say, saving some information by clicking on a “Save” button. This activates the controller and the information is passed to the model part of MVC. The Model validates and saves the data using an underlying framework to the database. Once the action has been processed, a notification message has to be generated for the user. Let that alert be, “Your information is saved”. This is passed by the model to the controller which in turn forwards it to the view part of MVC. The View finally displays the dialog box to the user notifying him of successful completion of the action he initiated.
GOING BACK IN TIME
The existence of MVC ranges back to its first ever use in Smalltalk-80 framework. Originally, it was very different from what is perceived today. It was interpreted as,
- MODEL – Some piece of data corresponding to an application.
- VIEW – A representation of data. However the data from the model might have multiple views.
- CONTROLLER-Collect user input and modify the model.
As we can see in the representation above, earlier, the view was updated directly by the model. As the model changed, the view changed accordingly. Also, the controller had no link to the view in contrast to the present day MVC where controller is sandwiched between the model and the view.
Having presented a contrast between the traditional approach and the modern one, let’s have a look at the benefits of MVC:
- Delegation of task: The three components – model, view and controller allow reusability of code.
- Focus: A developer of UI could focus on view while a developer of model can focus on business logic thereby leading to less coupling between the layers.
- Adaptable to change: Interfaces change frequently than business logic. The most important part being that a change in one part might not require a corresponding change in the other.
- Single Page Applications– Using the MVC architecture one can create a single page application.
Just as there are two sides to a single coin, MVC carries with it a few disadvantages as well.
- Complexity: With ease of doing tasks, there comes complexity in the whole process of making the task easier, that is, the applications supporting MVC are quite complex in nature.
- Frequent updates: Though it was mentioned that a change in one part might not require change in another but what if the view changes frequently while not the model. This way the scope of change is confined to view only.
- Unfit for small applications: MVC architecture is said to be unsuitable for small applications because it affects their performance owing to its high complexity.
Though there are some trade-offs, the pros surpass the cons. For a robust and secure code that is adaptable to changes, is more organized and not just a chaos, and offers high-end performance, MVC is the architecture to look forward to.