MVC? More like MCV.
I’m on the journey of deepening the knowledge I gained from my bootcamp experience. Along this journey, I would like to share what I’ve learned in hopes that it can help others and welcome any additional information to deepen my understanding.
If you’re in the middle of a bootcamp, self-teaching, or whatever your reason is for learning, I encourage you to be patient and practice, practice, practice! It takes different amounts of time for everyone to understand different topics. The more you expose yourself and ask questions about the topic you’re learning, the more things will start to connect. You’re doing that right now reading this blog, so take a moment and appreciate your great efforts.
So! The topic I would like to write about is the MVC architecture. MVC is a valuable and popular way to build your web app by separating your code to make it more readable, reusable, and DRY (Don’t Repeat Yourself). This allows new and experienced programmers to approach code with some common understanding. I’ll walk through the MVC architecture by explaining what it is, explain each part does individually, then explain how they communicate with each other using Ruby. The idea applies to other languages as well.
What is MVC?
MVC is an architecture, or way to build and organize code for CRUD functionality. It’s a way to separate code into manageable files instead of having one long, overwhelming file of code. CRUD is what allows us to manipulate data. MVC is where the communication happens to process the manipulated data. The M is Model, V is View, C is for Controller . I want to emphasize that the name MVC does not represent the order of communication between the three. I thought it did and was incredibly confused for longer than needed to be. I believe it should be named MCV for Model, Controller, View, which better represents the communication flow between the three, so I will go through each portion in the order of MCV.
The Model
The Model is what talks to the database, essentially storing or manipulating the data. Any code that is related to dealing with data, should deal with the model.
In this example, we have a model of the class of a user in Image A. Rails will do most of the work to map the class of User to the Users Table in the database. Image B shows the table of data for a user that is stored in the database. This is where the model is talking to the database.
Once the model has what it needs after talking to the database such as a user’s first name, it will then talk to the controller and handover the data to it.
The Controller
Now the Controller has the data (i.e. the user’s first name). This is where the data gets processed through an action such as def index or def show . The action decides the appropriate view file for which the data should be sent to. If action is def index , then the controller will pass data to the index.html.erb view file. Same idea if the action def show is needed, then the data will be sent to show.index.html.
The View
The View now carries the data(i.e. the user’s first name)in its appropriate views file such as index.html.erb for this example. The data will appear on the screen for the end user in a nice, humanly readable format, such as shown in Image C.
What was just shared was the purposed of the model, the view and the controller. The order was of MCV was also shown. First it was the model speaking to the controller, then the controller speaking to the view. Communication also happens in the reverse order which is the view speaking to the controller, then the controller speaking to the model. Here’s an example:
Someone sitting at a computer is what will start chain reaction using the view. Say they’re at google.com needing to search for an image of a chicken. Currently, the view will show a search bar and a button to start the search. The user will type in “chicken image” and then click “Google Search”. The view holds the data of “chicken image” and passes it onto the Controller. The Controller will then process the data and tells the Model what it needs. The Model now has the data of “chicken image” and will search for chicken images in the database. Once it has all the appropriate data, it will then pass it back down to the Controller. The Controller now has all of this data on “chicken images” and passes the data to the appropriate view. The view will now turn the data into nice images of chickens for the user that requested it. All of this happens quickly! Go ahead and google search “chicken images” and see how fast that happens.
I hope this explanation was helpful. If not, I have some other video resources I found useful. Please share how you understand the MVC architecture (should be MCV) or point out some areas of improvement needed in my explanation. I’m always open to becoming more proficient.
Extra Video Resources
Ruby on Rails: Understanding MVC architecture | lynda.com overview — Provides clear, quick overview with more diagram images to explain the communication flow.
Intro to Rails: The MVC Setup — This video is my favorite. There is a small walk through with code which was really helpful. It does not have diagrams to explain the flow.
What is programming MVC? [Detailed Explanation] — The speaker goes into more detail (sometimes too many details with low significance), but has a good diagram and explanation for the flow of MVC.
