DEV Community

loading...

Explain MVC like I'm five

andrewsmith1996 profile image Andrew Smith ・1 min read

Discussion

pic
Editor guide
Collapse
rhymes profile image
rhymes

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.

Collapse
lepinekong profile image
lepinekong

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 twitter.com/lepinekong/statuses/66...

Collapse
rhymes profile image
rhymes

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

Thread Thread
lepinekong profile image
lepinekong

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

Collapse
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.

Collapse
cmelgarejo_dev profile image
Christian Melgarejo

This one made me hungry now <3

Collapse
c_budah profile image
Collapse
josenriagu profile image
Josemaria Nriagu

Very beautiful analogy!

Collapse
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.

Collapse
maccabee profile image
Maccabee

This is pretty good 😊.

Collapse
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.

Collapse
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

Collapse
jhaeger profile image
Jason Haeger

This one is great!

Collapse
aligoren profile image
Ali GOREN

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.

Collapse
azder_16 profile image
Goran Peoski

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

there #FTFY

Collapse
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.

Collapse
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 -> ).

Collapse
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.

Collapse
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!

Collapse
yechielk profile image
Yechiel Kalmenson

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

Collapse
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.