Ordering Food and The MVC Architecture
Welcome to the MVC restaurant!
The Model-View-Controller (MVC) architecture is a tried and true form of building modern day web applications. You’ll encounter this pattern in a number of frameworks such as Ruby on Rails, Django, or Angular and it has allowed developers the ability to organize code in a way that separates files based on the job they do. This is a principle of web development called “separation of concerns” and it’s based around creating files with specific jobs and having them interact in a very defined way. Here’s what it looks like:
- Model: Structures your data in a reliable form and prepares it based on controller’s instructions
- View: Displays data to user in easy-to-understand format, based on the user’s actions
- Controller: Takes in user commands, sends commands to the model for data updates, sends instructions to view to update interface.
What does this have to do with ordering food?
I’m sure you’re confused about the title but I promise it’ll all make sense very soon! Learning new concepts can be difficult sometimes, especially if you can’t figure out a good comparison for it, but a restaurant is perfect for the MVC architecture.
The main goal of visiting a restaurant is to eat yummy food, but how exactly do you know what food the place is serving and how will you get this food?
Usually the host will walk you to a table and hand you their menu. The menu will represent our view which gives you, the user, a detailed list of all the food the restaurant serves. This makes life significantly easier for us because we don’t have to guess what food we can order and we can see exactly what comes with each dish.
Okay, so now we’ve had to time to look over the menu and have decided what we want to eat, but how do we communicate with the chef?
This is where our waiter comes in and for our example they will represent our controller. The waiter will facilitate our request by writing down our order and then bringing it to the chef who will actually prepare the food. In the MVC pattern, the controller is responsible for providing instructions that will tell the model what to build and then take that manipulated data and deliver it to the view.
For instance, you can have the controller respond with JSON data. You could also have it contain strict instructions for what data can be provided to the model, such as “strict params” which is commonly used in Ruby on Rails.
I can imagine you’re starting to get hungry at this point( I know I am) but don’t worry, we’re finally going to make the food!
After our waiter(controller) has taken our order from the menu(view), they will provide this information to the chef who will cook our food. The chef represents the last piece of the pattern which is our model. Our chef might be one person but they contain all the knowledge, or logic, to create our order.
In the MVC architecture we create models which are responsible for manipulating the data based on instructions provided by the controller. This allows for consistency throughout our application output and will provide an enjoyable user experience.
Let’s quickly go over everything we just talked about:
- The user makes a request from the view(menu) which uses a route, such as
- The controller(waiter) then receives this request and provides instructions on what to do. These orders can either go to the model where it performs certain logic, or it could go to the view and possibly update or serve a specific page.
- If it goes to the model, then it carries out the logic, pulls from a database and sends back a consistent response based on the controller’s instructions.
The MVC architecture is a great pattern to learn and it will make learning any new framework that much easier because they all follow some form of it. This provides consistency in structuring any application you build and will allow you to stay organized, which is critical as your app starts to grow.
Just remember the restaurant when working in an MVC architecture and you’ll be smooth sailing! Also might wanna bring snacks…