In the past couple of years, my professional life has been blessed with the knowledge of the MVC pattern. What in the world is this MVC I speak of? MVC stands for Model-View-Controller, and it’s an idea behind application development to separate the 3 main pieces of the application into their own isolated environments.
What does this mean exactly? There are three major components of any given application, be it a desktop application, mobile application, or a web-based application. These three components are the Controller, the View, and the Model. Now let’s get a more concrete idea of what each of these three components actually does within an application.
The Controller is essentially the traffic cop of the application, directing traffic to where it needs to go, figuring out which view it needs to load up, and interacting with the appropriate models. For example, when you go to login to your email on a website, the controller is going to tell the application that it needs to load the login form view. Upon attempting to login, the controller will load the model that handles logins, which will check if the username and password match what exists within the system. If successful, the controller will then pass you off to the first page you enter when logging in, such as your inbox. Once there, the inbox controller will further handle that request.
In a web-based application, the view is exactly what it sounds like: the visible interface that the user interacts with, displaying buttons, forms, and information. Generally speaking, the controller calls up the view after interacting with the model, which is what gathers the information to display in the particular view.
The Model is where data from the controller and sometimes the view is actually passed into, out of, and manipulated. Keeping in mind our last example of logging into your web-based email, the model will take the username and password given to it from the controller, check that data against the stored information in the database, and then render the view accordingly. For example, if you enter in an incorrect password, the model will tell the controller that it was incorrect, and the controller will tell the view to display an error message saying something to the effect of “Your username or password is incorrect.”
Now that you know the basic concepts of the MVC pattern, you’re probably wondering what makes it so special? Essentially, it allows for the programmer to isolate these very separate pieces of code into their own domain, which makes code maintenance and debugging much simpler than if all of these items were chunked into one massive piece. If I have a problem with an application not displaying an error message when it should, I have a very specific set of locations to look to see why this is not happening. First I would look at the “Login Controller” to see if it is telling the view to display the error. If that’s fine, I would look at the “Login Model” to see if it is passing the data back to the controller to tell it that it needs to show an error. Then if that’s correct, the last place it could be happening would be in the “Login View.”
Using this development pattern allows for very easy maintenance, as well as independent development of pieces of the same system by different programmers, which makes for quick turnover of applications all while still maintaining a very high standard of quality for the application.