For further actions, you may consider blocking this person and/or reporting abuse
Read next
Beginner SEO in React JS - React Helmet
Neer S -
Effortless API Documentation with Grape, Grape Swagger, and rswag-ui
zenkul -
Mastering Docker Image Building: A Complete Guide to Creating Efficient Docker Images
Abhay Singh Kathayat -
Understanding Docker Image Layers: Best Practices for Building Efficient Docker Images
Abhay Singh Kathayat -
Top comments (21)
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.
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...
I don't really know any five year old who's also a statistician 🤣
It's not because you've never met one that he doesn't exists ;)
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.
This one made me hungry now <3
🤣😂
Very beautiful analogy!
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.
This is pretty good 😊.
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.
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
This one is great!
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.
Model = Your brain
View = Your clothes
Controller = The rest of your body
there #FTFY
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
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.