The Model View Controller Paradigm is one of the most fundamental programming patterns out there. It is at the heart of practically every website and every iPhone app (and the good android ones too!). Understanding MVC is critical to writing maintainable software, and even though new acronyms have come out since (MVP, MVVM, HMVC) all of them try to capture an ideal defined by MVC.
In this section we will first discuss what programming patterns are, then we will delve into a brief description of each component in MVC. Throughout this description we will be talking about how MVC can be used in sample applications to make life easier for programmers, and the experience better for end users.
Programming is all about patterns and conventions. C programmers know that when they see something named IN_ALL_CAPS that the value is constant. They know that i is an index and that foobar may be a variable or struct. C programmers use naming conventions constantly, often not realizing how important they are, to make programming easier. In the same manner, web developers, iPhone app makers, and sensible application programmers rely on the MVC paradigm to make large projects easier to understand.
More important than writing efficient code, or writing code quickly, is writing code that is human readable and self documenting. It is tempting, especially when learning to program, to work quickly. But Facebook was not written in a day. At the time of writing, the Facebook iPhone app consists of over 18,000 class files. (Take a look) So how can a handful of people on Facebook’s programming team manage that many files? Well they better be using patterns (spoiler, they use MVC).
Patterns, in my opinion, are all about knowing where to look for something. Are you wondering how to add a feature to the login page? Well, that’s a lot easier if there is a file for login graphics, a separate one for login logic, and a whole other system for login data (otherwise we might lose some users due to minor text fixes).
So without further ado, let’s look at Model View Controller.
In order to understand each piece of the MVC pattern, we will first see the macro-level organization of the three components and how they interact to make up an application at a high level. Then we will give details about each one.
As the above image outlines, the controller sits between the model and the view, providing a level of abstraction between the two. We see that data moves from the model to the view through it, and similarly, events from the view can lead to updates to the model in a reverse fashion. Overall, the most important thing to see is that no communication happens directly between the View and the Model. (In my opinion, the acronym MVC would be better written as MCV because we don’t want the M and the V too close to each other).
Now, we will start from left to right in the above diagram and see how additional layers of abstraction eventually get us from raw data to a human usable application.
A database, a sensor network, a large text file, or even RAM could all act as models. Typically a model is a data source, often logically separate from the whole application. Imagine a website like Facebook or Reddit. Somewhere, they have to store everyone’s login, their posts, their pictures, and anything else the user needs to see on the website. This data, likely stored in a large array of servers, consists of the model. The model can be queried and updated, but the model itself knows nothing about the application its data will later serve. After all, a picture in Facebook’s database shouldn’t be different based on whether it's going to be displayed on a computer, tablet, smartphone, or exceptionally modified toaster.
The Controller houses all of the logic of an application. Simply put, the controller is the only component that actually knows what going on. For example, there is a different Facebook controller for the website and the mobile app. It’s the controllers job to understand the context the application is living in. For instance, when a user logs in, a controller needs to store the user’s credentials in order to know which user logged in. This allows the controller to request that user’s information.
In many MVC apps, almost all of the code occurs in Controller classes, and there can be a lot of them (facebook’s 18,000 classes are practically all controllers). This is because controllers should be small and single purpose, talking to each other to achieve complex interactions. In a mobile app, there should likely be a single login controller, but there might also be a separate “register” controller for when a user makes a new account. There will also likely be a single controller for each screen or interaction present (a chat controller, a comment controller, a controller to show new posts etc.).
Using many small, single purpose controllers makes programming easier when coordinating with teams (or when coordinating with yourself after not looking at a project for over a year). If there is a bug with login, look at the login controller, chat bugs are in the chat controller, and so on. Making new features is as easy as making new controllers and linking them in. Testing is also really easy, because each controller component can be evaluated in isolation.
Another note about testing, because the model is very separate from the controller, evaluating an application in a test environment with dummy data is also very easy. Imagine somewhere inside your web application you have a string databaseUrl = “www.someWebsite.com/database”. With almost no work at all, this could be changed to “localhost/testDatabase” and assuming everything is configured properly, the application would go on as if nothing special happened.
Lastly, we get to the view. This is what the end user actually sees, scrolls through, clicks on, and considers to be your application. The view is therefore exceptionally important, even if it should not (read: DOES NOT) have any understanding of the application as a whole. Example of views might be a single post view on the facebook mobile app. A single post has a picture, a title, a description, and a couple of buttons, but the post view needs to be used over and over again for each post the user sees. Additionally, the like button on each post needs to be slightly different; each like button needs to correspond to the right post.
In some cases, a library might form most of the view. For example, JavaFX is a GUI library which provides things like a canvas that programmers can draw on. That canvas object might be the entirety of the view, and it’s the job of some controller to decide what gets drawn on that canvas. As a rule of thumb, a view object should be constructed to make programming its corresponding controller(s) simpler. Facebook likely has a post view, a chat view, and a picture view because those components are reused often in many places in the app.
The view should have no knowledge of what it’s displaying. The view shouldn’t even know what happens when its buttons are pressed. Instead, when a button is pressed, the view should simply inform the corresponding controller of the button event. In many libraries, the view doesn’t even need to explicitly do this. For example, back to JavaFX, a handler object can be added to a view’s onClick method. That hander object can be placed by a controller to allow input to bypass the view’s logic completely.
The model is a database or some similar system. The view displays information that is given to it, but has no power to request information itself. And the controller is like a puppet master which coordinates between them, taking information from the model, sending it to views, receiving input, and updating the model.In this manner, large programs, websites, and apps can be maintained by large software teams over the course of years.