MVC, What Is It?
Hello, I know it’s been a little bit since I have published anything new. I want to start off by apologizing for that. I have since changed jobs and it has been a bit of a learning process about getting up to speed with the three projects that I will be maintaining and updating with new feature requests. Enough about work related tasks, let’s move on to the reason for this article.
I wanted to write an article that gives a brief understanding of MVC. I have noticed that when speaking to some up and coming developers in the web space that MVC seems to be a lost art in a lot of ways. Now some of you might be saying that “But MVC is a lost art. We have SPA s now.” While that is true we do have SPAs and they are definitely becoming the defacto standard if you will. Using the MVC architecture doesn’t mean you have to give up your SPA design. On the contrary I believe that using MVC would be a benefit to your project as it would give it structure. With good structure comes great productivity.
If you are a new developer, or even new to web development, learning MVC will help give you a rough idea on how to organize and structure your code. With more experience you will be able to adopt custom design patterns that will ultimately work better for your applications, but MVC is a great starting point for almost all apps. There is a reason that MVC frameworks like Python’s Django, Ruby’s Rails(Ruby on Rails or RoR) and to a certain degree JavaScript’s Sails.js are still used to this day. They provide a structure and organization pattern that helps a team or individual bootstrap an application quicker and more efficiently than if you were just starting from scratch and needing to put all your code files together in directories.
Model View Controller(MVC)
If you have been coding for a little while now, give or take a few years or so, you will no doubt have noticed that some code bases are easier to navigate through than others. Those same code bases are easier to maintain and even update compared to others. To one that doesn’t have the experience it can be a fog or cloud that hides the reason these code bases are easier. The biggest reason is the organization and structure the code base uses.
If you need to jump in and start adding a new feature, fixing a bug, or even updating an existing feature it is a lot easier to do if you can take a guess where in the code you need to start looking. When you have no idea where to start, you end up wasting a lot of time digging through source files. With a well structured program you can often guess where the code is even if it’s your first time reading through the code.
Model View Controler — aka MVC, is an architectural pattern that is designed to help organize applications by separating code based on what it is responsible for. The developers are then responsible for making sure that the correct code is put in each package. The MVC pattern introduces three distinct roles that code can fall under.
Views —
Views are responsible for rendering data. Simple I know, but that is all they need to do. Given a specific page and data for that page, the views job is to generate the correct output for that page. The view is typically HTML code that is returned to the end user’s browser. This could vary of course as you could use say React instead of just HTML. The most important thing to remember for the view is that there should be as little logic as possible. Too much can cause problems with debugging and maintaining the app as it grows. So keep that in mind.
Controllers —
Controllers are used to handle the business logic that happens behind the curtains for a web request. It doesn’t directly create views, or update data in the database, but instead will use views and models to do these things. Most of the analogies for controllers uses the Air Traffic Controller as an example. Air traffic controllers are the people that instruct each plane at an airport where to fly, when to land, and on what runway to land or take off from. They aren’t actually in control of the plane but are speaking with the pilot constantly updating them on where to go. Similar to views the controller shouldn’t have too much logic in it, but will instead pass data around to different pieces of your application that actually handle performing whatever work needs to get done.
Models —
Models are responsible for interacting with your raw data. This typically means interacting with your database, or even data from other services or APIs. A good example would be a web app that has user accounts. You want to represent them in a database as user objects. In order to access the data you would create a User model that is a representation of the data from the database. This User model will handle doing things like updating a user’s contact information in the database.
One final note to make on the MVC architecture is that while these three categories are important and heavily used this DOES NOT mean that you have to put your code strictly in one of these three categories. You can create several other packages or directories that will work alongside these three primary categories. One such example that comes to mind is a router. You can create your own router directory that stores all of the logic for the routing package.
Brief Walk of a Web Request
I have found it to be a bit easier to understand if you have an example request to kind of look at. Below is a typical request for a user of Steam to change their password.
1. Password change request
This is typically done when a user goes to their account settings and requests a password change. The request is then sent to the server, where the router is the first code to take action.
2. The router decided that the UserController should be used
The router, upon receiving the request, realizes that this is a request to update a User’s password based on some criteria. In this case the URL and HTTP method, it then forwards the request along to the UserController to handle the request.
3. The UserController uses the User model to update the User’s password
The UserController handles the request and needs to make a change to data stored in the database. However with MVC the controller doesn’t interact directly with the database. The controller instead will use the User model to update the password, thus isolating our database specific code so that the controllers don’t need to worry about it.
4. The User model returns the updated data to the UserController
After updating the password for the user in the database, the User model will then return the updated user object to the controller so that the controller can use this in the rest of its code.
5. The UserController uses the ShowUser view to render the correct template/html
Once the user controller gets the user back, it will then use the corresponding view to render the data. Again this allows the controller to operate as more of a director that decides what code should run next. It also won’t get bogged down with a ton of logic of its own.
6. The end user sees the Password updated successfully message
After everything is said and done, we should see the message indicating that our password was changed successfully.
Conclusion
This was a small and high level overview of how MVC works. In the example I used the Steam client indicated by the Steam logo but this could very well be a browser that initiates this call. I wanted to show it in this manner as it would reflect an API call versus a browser call in order to better showcase that either would work in the situation. I hope that this helps anyone looking into this manner of coding web apps.
