The MVC Framework

For my second writeup in the software development series, I’d like to give some personal insights into what might be the most central concept to web applications development: the MVC structure. I’ll be giving some level of analogy as to how apps function using relatable real-life illustrations. I’d like to also say that the points expounded in this post wouldn’t be an in-depth analysis of everything MVC; think of it as an attempt to scratch the surface of an integral part of web apps development.

If you’re an outsider looking in, I know you’re definitely wondering: What is MVC? Well, it is simply what makes your various apps able to do everything you instruct it to do. Yeah, the facebook, instagram, twitter apps on your phones are basically exemplification of MVC at work. Everything from you logging in, checking a profile, making a post, booking a flight, paying for an item on amazon, etc. These all have something to do with the framework that is MVC

MVC is an acronym for Model-View-Controller. An example which immediately comes to mind is a customer that goes to a restaurant for some food. He is in this case the view, he makes some request through the waiter (the controller) and the waiter informs the cook (model) of the request made by the customer. The waiter in turn delivers the food to the customer.

When you launch your app, you get back what we call the V (view) of the MVC. It is through this view you’re able to read the content of the page and/or “talk to”/communicate with the app. Talking to the app is essentially you sending information for instance “liking” a post on Facebook changes the button to blue. You get an immediate response in this case. In some other cases if you tell the app that you want to see the content of a facebook group, you’d wait a couple seconds for the group’s (view) page to load and you can do some more talking to the app about that group.

When you click on any content on the app, the Controller (“C” in the MVC) takes your request and directs it to the appropriate channel and the content within that channel is sent back as the view which you then see displayed. The controller fulfills the request by communicating with the Model, which in turn has access to a database that stores all of the information you’re requesting when you click on an item. This same logic applies to when you’re shopping on amazon: Through the view, you see for instance a footwear type you like, click on it and are directed to a page that contains more information about that particular footwear, including its price. If you want to buy, you push a button and the controller requests that a cart model be loaded, taking in that footwear and any other item you want to purchase.

To go a little bit into actually developing this, let’s write some of the simple parts of these code in the Ruby language. Assumption made here is that there are no Javascript / front end code, no CSS, and this particular amazon only sell shoes. Also, the various routes are assumed to have been pretty much handled by Rails, a framework for the Ruby language. Your typical amazon search bar looks like this (fig. 1):

fig. 1: a typical amazon search bar

This is what the customer gets to see (the view in our MVC structure). The code that made the search bar possible looks something like the one given in fig. 2 below:

fig. 2: code that helps display the search bar in fig. 1

When the customer enters “air Jordan for men” in the search bar, a controller (C in MVC) action runs, asks some information from the shoe model and gets a response that displays all air Jordan shoes horizontally (fig. 3).

fig. 3: all air Jordan shoes available in database

This controller action is a single line of code (lines 3–5, fig. 4 below) that collects all shoes in the database (the controller actually calls on the “Shoe” model which in turn requests it from the database). Just imagine database to be a store house for data or information:

fig. 4: some important controller actions for shoes

The customer then proceeds to select one of the shoes from all the options and this in turn fires another controller action (line 7–9 of fig. 4) which gets the particular shoe that was selected and sends it to the appropriate view page (fig. 5):

fig. 5: displaying a particular shoe from a collection of shoes

Since this is a whole new page displaying just a single item, it means we must have had some code in some specific shoe’s page. The code that renders the above is something like:

fig. 6: example of code that makes fig. 5 possible

Note that this code works for every shoe type selected. The code is written in such a way that it’s responsive and can adapt to whatever shoe is selected. The customer then can decide to add this to their cart and checkout.

fig. 7: a typical “add to cart” button on amazon

The add-to-cart event is also made possible by an appropriate controller action which creates an instance of the cart-shoe “join” model (line 7–9, fig. 8):

fig. 8: controller actions for creating a cart and adding a selected shoe

When the customer pushes “checkout”, a form is displayed in which they can put in their payment information and pay for the shoe.

And just like that, a customer completes the cycle from search to purchase.

Overall this is a simple way to introduce the MVC structure. It’s intended to only make the reader flow with and understand how code runs together to make the customer experience hitch-free. There are also many different ways to write the same code so this is by no means some authority. Please feel free to let me know of comments, concerns or anything you like about this blogpost.