Model.View.Controller (MVC)
AKA Most Valuable Concept
When I was first introduced to the Model-View-Controller(MVC) model, it seemed like we were just adding unnecessary steps to an already complicated process. Why separate the Model, View, and Controller when they communicate with one another? However, after having worked with MVCs for some time now, it is easy to see how connected this framework is to the idea of Separating our Concerns(SoC). Remember, separating our concerns — whether they’re through higher order functions (HOFs), Classes, or other frameworks frees us from debugging headaches and allows us to reuse code whenever needed while keeping our code DRY. Although it may take some time and practice to fully grasp the order of things, this concept will allow you to streamline your code while giving you the logical clarity needed to implement your design, in turn helping you become a better programmer. In addition, MVC makes up a large part of today’s most popular frameworks — Backbone.js, Angular.js, EmberJS and KnockoutJS. In this piece, I will break down what each part of the MVC does, how they communicate with one-another, and what the expected results should be.
What is MVC?
The MVC is a programming framework by which we separate an application into three separate components — the model, the view, and the controller. These components are built to handle specific development aspects of an application and make up one of the most frequently-used web development frameworks around. To help understand how this might look in daily life, I’ll use the example of a bank account and an ATM.
Model
The model component of a program corresponds to the storage and maintenance of all the data that needs to be worked on. The model is responsible for listening for instructions from the controller and responding accordingly. The model can listen to several controllers and interface with multiple models to represent a variety of views. Let’s unpack that for a moment. When thinking of a bank account, the model will refer to all the data related to a bank account. This information can range from personal information like residency, name, and DOB, to your account balances. Your account balances themselves may be different models that only communicate with one another when money is being transferred. When viewing your account through via an online platform, the information conveyed (or the view) may change depending on your request. In this case, the data within the model is not changing, it is merely reacting to instructions from the controller in order to output the view required.
Controller
The controller component acts as the middleman between the model and view components. It is here where tasks are performed and incoming requests are used to manipulate the data inside our model, and sent to the view to render. Put simply, the controller listens for events on the DOM (like clicks, submissions, etc…) and passes the information to its associated model. As was previously mentioned, there can be many controllers for one model, but it should be noted that a controller can only pass information to one model. Using our online banking example from before, the controller is responsible for showing us specific information depending on what data we desire. If we want to find out the balance of a specific account, we can simply click on that account and the view will render data specific to that account. If we decide that everything looks alright and we want to see what our credit card expenses are, we would click on our credit card statement and a different controller would transfer our request over to our credit card model in order to render that specific information.
View
The view component is the endpoint that the user deals with on an everyday basis. This can be thought of as the way data is represented and shown to the user from the Model. It should be noted that the View and Model do not communicate directly with one another in order to achieve this end. Rather, the View initializes its own Controller in order to initiate and output the desired results. In much the same way as the Controller, the View can only render data from one model. In our online banking example, the view would be the interface that we see. When we login to our account and are presented with user-specific information, that login process initiated a Controller function that performed a request onto a model. The model then outputs the Controller-specified information to the View, where it is rendered in a readable manner. Now let’s say you were at an ATM. The View, and Controller would be different than the ones on your computer, but the same Model information would be accessible to you. Although you are interacting with a different machine that has a different output then your computer, the Views are able to render user-specific information due to the Controller’s ability to interpret the View’s request.
The diagram above gives a rough visual outline of how these parts interact. As you can see, the view sends instructions to the Controller, which then toggles a data-specific request in the Model that is then output to the View to handle and display. In doing so, each component maintains the separation of concerns and allows us to organize our programs in a way that won’t corrupt the data. I hope this helped clarify some sort of understanding of the MVC framework!