WTF is MVC?

WTF is MVC?

MVC so that you can actually understand it

SO! Obviously you’re here because you want to know about MVC. Like…what exactly is it? Well first let’s talk about what MVC isn’t.

1. A language
2. A framework

Great! so- what IS MVC?

It’s just an idea, and a good one. Someone had an idea for how to structure an application, and called it “MVC” which stands for: Model – View – Controller. That’s it.

Now that you know what it isn’t, and what it stands for- let’s get into the individual parts; how it works, what it does, and why.


The View:

We’ll start with the easiest concept to understand- the view. This is actually, exactly what it sounds like. The view is simply what you’re currently seeing. It’s the presentation. The user interface. The HTML rendered to the screen to show you stuff.

The Model:

Next up is the model. This is going to be a model of your data. Get it? It’s like a blueprint that explains the layout of your data and how it’s presented. So, say you have a user object in your application- the model representing that user might specify properties such as username, password, ID, email etc… and it will interact with a database to retrieve or update that data.

The Controller:

The controller is like the supervisor of the application. It delegates tasks, tells everybody else what to do, and keeps certain aspects of your application from interacting. The controller manages incoming HTTP methods (GET, PUT, POST, DELETE), receives data from the model, and tells the view how that data should be presented, before finally rendering it to the screen.


How it works:

Let’s visualize the MVC flow as a coffee shop.

The Controller will be the supervisor.

The View will be the waitstaff.

And the Model will be the coffee…chef.

So, say you go to the coffee shop and order some data, a frappuccino, from your waiter. Well the controller, or supervisor in this scenario, hears that REQUEST for a frappucino and handles that request by shouting GET ME A FRAPPUCINO to the coffee-chef, the Model. The coffee-chef knows that a frappuccino should have a size: which is a String “small”, “medium”, or “large”, an option for Ice: which is a Boolean-True or false. And a sweetness-level: which is an integer. That is the structure; or rather, MODEL of this data beverage. So, a frappucino is retrieved from the kitchen (A database) by the coffee-chef. Now how do we get that beverage to you? Well, say Halloween is just around the corner, so we want your data to be rendered in an orange cup. The supervisor tells the waitstaff (the view) to pour your frap into a bright orange cup. Now, the small, sweet, iced frappucino is finally presented to you.


But What’s The Point?

I know what you’re thinking. “Great analogy” but what exactly does all that do? Well, I want you to think about it for a second. In that example, did the chef need to tell the waitstaff to use an orange cup? Did the waitstaff need to know if your drink was sweet? No, they never even needed to communicate, yet the data, your frappuccino, still made its way to you.

The MVC structure promotes a separation of concerns. By putting core aspects of an application into their own little bubbles, the overlap between them is greatly reduced, which leads to less complexity. This encapsulation facet of MVC structure allows for changes to be made in one area without negatively impacting other areas. Code becomes more flexible, reusable, easier to maintain, and better organized following an MVC format. Say you’d like to focus on the UI of an application. You could make as many changes as you want to the view, but the actual data would never be affected.

Let’s look at a quick example using javascript and express:

Say a user interacts with the View, maybe clicks a button to retrieve some information.

A request (we’ll use a GET request) is then sent to a path:

app.get(‘the path’, “request handler function”)

A Controller will take on the role of the request handler and decide how to handle the incoming request:

app.get(‘the path’, Controller.function-That-Handles-GET-Requests)

The controller will look to the Model to interact with any data (we can visualize the Model as a simple object):

Person = {

name: { type: string}

good-dancer: { type: boolean}

}

Which will in turn respond to the Controller, and update the view-

function-That-Handles-GET-Requests: (request, response) => {

//ask model to provide data

// model does stuff with data…

//Send data to view… }

See? Easy Peasy.

Hopefully I was able to shed some light on this topic. I’ve seen a few articles that sort of talk to you as if you’re supposed to already know what everything means. MVC is a fairly common design pattern so hopefully, I was able to make it make sense.