What is Model-View-Controller?

Over the last year and a half (and especially the last 3 weeks as student at the Flatiron School), I’ve spent a lot time learning the fundamentals of Ruby. I built a couple of CLI’s (Blackjack, War) before I got to school, and these were fun and informative exercises. But what I really want to do is build real Web Applications. My problem has been until recently, that the how of this has been a mystery. Enter the Model-View-Controller design pattern.

Conforming to the separation of concerns and the single responsibility principle, MVC aims to improve the writing, reading and debugging of your code by separating it into three main categories.

Model: contains all of an application’s data, and has the ability to manipulate that data. It has no interaction with the View, but does communicate with the Controller.

View: is everything that you, the user see in the browser. Usually HTML, CSS and Javascript. It’s pretty dumb, and never has any interaction with the Model.

Controller: Definitely the coolest element of MVC. It takes in requests from the browser, contacts the Model for any data it might need, and then grabs the proper View to display that data to you, the user.

Flatiron uses the analogy of a restaurant to explain how MVC works. I found this extremely helpful so I’ll share it with you.

In a restaurant, the Chef is the Model. It’s job is to take orders (requests) from the Waiter and create some awesome food for the Waiter to deliver to the Customer.

The Waiter is the Controller. They take in orders (requests), take them back to the Chef (Model), and then deliver the proper meal to customers (Users).

The Table is the View. It just holds whatever meal the Waiter brings back from the Chef.

The clean and straightforward structure of MVC has helped me understand more of the how of building Web Applications. I’m excited to build my first web app and I hope this blog helps others in a similar place on their coding journey.