Wednesday, December 3, 2014


Everytime I see MVC, this is what I think of.

When I finished my first Rails app a couple weeks ago, I ended it with a sort of hand-wavy, very very tenuous understanding of the MVC pattern in Rails. Like Rails was the roof of a tall, tall building that I was hanging over the very edge of my fingertips. It mostly went like this: 

Ummm...the controller figures out some stuff, and the view shows you some stuff, and the model does...something.

Now I'm into my second app, and my understanding is starting to sharpen. The MVC (Model-View-Controller) idea is that there are three high level functions an app needs to be able to do, splits everything out into things that fall under those three functions, and then provides ways for those three chunks of functionality to coordinate to TCB. (See what I did there? Using TCB in place of take care of business, because it's a three letter acronym like MVC and PYT? OMG.)

So, I'm thinking about this app I'm making (A Twitter clone, more or less) as a restaurant kitchen, receiving orders, preparing dishes, and sending them out to the customer. There's a dining room full of users, making orders and dining upon the food they receive. In order for this to work, a number of things have to happen: 

  1. An order needs to be placed
  2. The order needs to make it to the kitchen
  3. The order needs to make it to the chefs
  4. The ingredients need to be gathered
  5. The ingredients need to be cooked to specification
  6. The meal needs to be arranged pleasingly on the plate (eye appeal is half the meal)
  7. The finished meal needs to be brought out to the customer
This is essentially what the MVC does! So let's follow that process using computer-y talk and the metaphor at the same time. Our customer is the end user. When they click something in the app, it sends an order to the kitchen manager (because our restaurant is big enough, with a wide enough range of options, that we need kitchen managers.) Our kitchen manager is the Controller.

The kitchen manager's job next is to deliver the order to the chefs. This is a big restaurant, though, with a lot of menu items, so there are some specialize groups of chefs - like the pastry chefs, and the meat cooker person or whatever, the people who do the salad course, etc. The bigger and more varied the restaurant, the more specialized chefs you need. These chefs are the Models and, just like the kitchen, the more complex your app is, the more models you need. 

Once the cooks get the order, they go back to the walk-in fridge to get the right ingredients to put in the right parts of the meal. Similarly, the model gets the right information from the database and gets it into the right form. When the ingredients are all together and in the right place they are returned to the kitchen manager, i.e. the model returns the information from the database, in the requested format, to the controller. 

At this point, the meal is technically ready, but you wouldn't send it out to the customer, because it looks terrible (eye appeal is half the meal). Just as the controller doesn't send the information it receives from the model without first making sure it looks right. To take care of this problem, the kitchen manager takes the meal over to the people who specialize in plating. They're the ones who squirt the pretty sauces onto the plate in a pleasing pattern, and who place the whatever into a meticulous fan arrangement and who wipe around the rim of the plate, so the meal looks just so. This is the View (which is what someone says at the beginning of that lady talk show every morning, I guess). The view takes that information that came from the model, and arranges it for the user. 

Once the view has had its way with the information from the model, it hands the plate back to the controller, who then brings the plate out to the user. Who then clicks something else, and the whole process begins anew.

No comments:

Post a Comment