DEV Community

Andrew Smith
Andrew Smith

Posted on

Explain MVC like I'm five

Top comments (21)

rhymes profile image
rhymes • Edited

This is a hard one to explain to a five year old.

Essentially MVC is about responsibility.

I would tell the kid that there are three people working in a shop. One is responsible for taking customers requests, one is responsible for fetching the item the customer wants and the third one is responsible for wrapping it in a nice packaging and giving it back to the customer.

lepinekong profile image

Not so difficult if you think about MVC like ... a statistician :)

M=Variable under Observation
V=Projection of M from several Viewpoints
Controller=holds the transformation rules

posted a few years ago

rhymes profile image

I don't really know any five year old who's also a statistician 🤣

Thread Thread
lepinekong profile image

It's not because you've never met one that he doesn't exists ;)

matteojoliveau profile image
Matteo Joliveau

MVC is a pattern composed of three parts, the Model, the View and the Controller.

You walk in a McDonald and you order at the big interactive touchscreen.
The screen is the View, and you ask for your meal there.
The order is passed to the operator, who is the Controller, that will go in the kitchen and fetch a burger (your wanted resource) of the type (Model) you asked, then deliver it back to you.

The View handles user interaction and presents data.
The Model represents the type of resources the application can deliver.
The Controller is responsible for coordinating requests and responses.

cmelgarejo_dev profile image
Christian Melgarejo

This one made me hungry now <3

c_budah profile image
Sbusiso Madlopha


josenriagu profile image
Josemaria Nriagu

Very beautiful analogy!

carywreams profile image
Cary Reams

Three friends: Smart, Artsy, and Bossy.
The bossy one listens to the smart one, telling the artsy one what to draw.
The bossy one listens to the artsy one, telling the smart one how the world reacted to the drawing.

maccabee profile image

This is pretty good 😊.

sam_ferree profile image
Sam Ferree

Mark understands the toys in the toybox
Vicky knows how to set out toys for certain games.
Charlie tells Mark to get the toys for a certain game, and tells Vicky to set them out.
Vicky tells Charlie what new game the user would like to do.
This continues for the entirety of play time.

jenessawhite profile image
Jenessa White

This one is really good Sam. I often think people forget to explain that the Controller doesn't do just 1-way communication!
Took me a few times to understand it originally without that clarity

jhaeger profile image
Jason Haeger

This one is great!

itachiuchiha profile image
Itachi Uchiha

Controller: your brain

Model: your body

View: Your clothes.

When you think of something your controller start to work.

Any part of the arm, hand or body represents the model.

Any clothes represents the view.

Controller ===> Your brain ready to do something

Model ===> Okey but I need shoes to show something

View ===> You wear your shoes to show data from model.

When I started to MVC, I didn't understand what is the mvc. After then I coded MVC like this.

So, you should find examples from the real world. Because the people can't forget examples from the real world.

azder_16 profile image
Goran Peoski

Model = Your brain
View = Your clothes
Controller = The rest of your body

there #FTFY

hdennen profile image
Harry Dennen

A still life artist could work.
The subject is the model, the painting is the view, and the artist is the controller.

rakshitsoral profile image
Rakshit Soral

Well, I will try my best to explain it in a way such that 5 years Kidda would understand it easily.

Let's relate it to Banking System where you have bankers (Models), View (Customers) and Controllers (Average Bank employees) and Bank (Application)

These Bankers only have access to this large and safe DB system. Since more than often - they are lazy and fat (pun intended), they pretty much suit with the idea of MVC's Fat Models and Skinny controllers. They make all the important decisions such as ordering and managing Controllers which makes sense to relate it to another logic that "your business logic should be contained in Models".

Controllers (Average bank employees) should not make important decisions such as ask the Banker (Models) for every little information such as get the info and pass it to Customer (View). These Controllers (Average bank employees) cannot be dumb like customers are (this implies that little business logic in Controller is Okay, sometimes).

Now, suppose these Controllers (Bank employees) began to think too much then it will make the Model (Bankers) upset and it will create a havoc in your application (Say bank in this case).

Customers are now View which are dumb. They do nothing than talk to Average bank employees (Controllers). Furthermore, these Models (Bankers) are not supposed to talk with View (Customers) directly which follows other criteria of MVC (Models should not talk to View).

The communication between the Bankers (Model) and Customers (View) is controlled by Controller (Average bank employee).

Sometimes, it may also be possible that controller (single bank employee) has to get information from Model (Banker) and that is completely OKAY. Now, in this situation, these Models (Bankers) can also communicate with each other and pass on the information to the Customer (View).

Now, you ask me "What about View". Well, bankers sometimes do mistakes and Customers should be smart enough to balance their accounts. This analogy can pretty much deal with this ideology that "Views can contain some logic which can be related to the presentation". But they are dumb enough such that they couldn't tell the Bankers (Models) as to how to process these transactions.

funkybob profile image
Curtis Maloney

MVC lets you cleanly think about writing GUI programs.

It has a "Model" of your data, which emits events when its content changes.

It has a "View" of the data, to show it to users. This listens to the change events to know when to update. This, in turn, emits events when the user interacts with it.

Finally, it has a Controller, which reacts to events from the View, and does "the work", typically updating the Model.

It's a nice, clean, circular pattern... everything always goes forwards (M -> V -> C -> M -> ).

pinwheeler profile image
Anthony Dreessen

So you know the television?

Well when you're watching Netflix, the TV show exists as a bunch of little bits of information we call data. That's the model. The view is the screen and the picture that you get to see and the controller is the TV itself that takes the data from Netflix and turns it into the picture!

yechielk profile image
Yechiel Kalmenson

I wrote a blog post to explain it using a great analogy: Welcome To The MVC Restaurant

sparkcruz profile image
Roger Cruz

Nice, but I'd like to point out your food is the Model, the workers are Services. Having a model know how to communicate to the database is like having a chips package to sell itself, open itself, eat itself and then throw itself in the right garbage can. So either you have a Persistence Service or you Represent Data as it passes through your layers.
ActiveRecord is a lie.