The Ping Relationship of Model, View, and Controller(MVC)
CAN I SKIP THIS CONCEPT? WHY IS THIS EVEN IMPORTANT?
If you’re new to software engineering you’re probably trying to figure out the meaning of MVC. In fact, if you’re new to software engineering you’re probably wondering why can’t you just type all of this information inside one .py or .rb file. Just thinking about an entire code inside of a programming file gives me a headache. We need Model, View, Controller in the beginning because it creates structure.
The Model
What is our model? Why do we need the model? Our model is what connects us to the DB (database). If we need to modify any changes, we need to interact with the model. Take a look at the flowchart above, and imagine a company trying to implement a feature that enables communication. In this instance I will use phone calls as an analogy for the arrows in the flowchart. First, we need to create a table using a model. We “call” the model and ask it to create a table. The model responds that it has created a table with our requested attributes. Wow, that was easy.The Controller
THE CONTROLLER
The Controller is a middleman between View and Model. The Controller tells us what we can see once we send our GET request. Right now the controller job doesn’t seem important. A little later you will see the importance of the Controller.
The View
The View is what the user sees, depending on whether the application is built correctly. Technically what I’m writing on medium is one example of a use case. After I finish writing this article I will click publish and that updates the user’s front end perspective. Another example of a use case is the ability to see five posts a month versus unlimited articles for premium users.
How does this come together?
Prior to giving examples I wanted to explain the core concepts of what each function does. Now, I can jumble in some vocabulary that even I myself barely understand, and hope you can bare with me. I will continue with the phone analogy. I will contact a website (GET Request). This is all from a Back end perspective. When I phone GET Request, the GET Request phones me back telling me I have access to this server. I then call my Model to let my model know there’s something I want to manipulate in the database. My model will phone the Database to see if there’s confirmation it even exists; if it exists my Model gives the DB instructions to operate like this from now on. The DB phones the model back and confirms to the model the deed is done. The Model phones the Controller to tell them to remove this from the website or API because we were given instructions from the boss to remove it. The Controller then updates the changes to phone the View. The View receives a phone from the Controller to tell the View to let the user know the changes that were made. The View contacts our GET Request and that is what we see! Hope this article was helpful.
