I was intimidated by the model view controller (MVC) architectural design pattern because it’s hard to understand the abstraction before implementing it.

Just describing it introduces four or five abstractions that you have to get before you can understand what you're reading! It’s much easier to grasp once you try it out.

MVC Applied

Let's tell a little story about how it works. You head to google.ca to find your favorite website. If google.ca is running an MVC architecture behind the scenes here’s what happens, more or less.

You hit a Controller that is listening for your request. That controller is going to be helping you out with coordinating everything you need to get your webpage.

First, the Controller will likely reach out to an API or database to get you the information to build your search. It will likely get this data back in JSON format.

Second, the controller needs to model your data in a way that makes sense inside of your program. That data could come from anywhere, so the controller needs to represent it in a way its program can understand. It reaches out to the Model to instantiate a representation of the data you requested in your programming language of choice.

Finally, the controller provides the model to the View. The view knows how all the data should be displayed. The view is returned to the user and voila! You have your search results.

MVC allows for a clean separation of concerns between code. It’s easier to build and reason about a web application, especially when things get complicated, when you have well-defined abstractions like a model, view, and controller that each play a specific role in getting your web page out there.