Explain MVC like I'm five

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.

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.

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.

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.

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.

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

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

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.

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!

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