MVC (model-view-controller) - can it be explained in simple terms?

Question

I need to explain to a not-very-technical manager the MVC (model-view-controller) concept and ran into trouble. The problem is that the explanation needs to be on a "your grandma will get it" level - e.g. even the fairly straightforward explanation offered on MVC Wiki page didn't work, at least with my commentary.

Does anyone have a reference to a good MVC explanation in simple terms?

It would ideally be done with non-techie metaphor examples (e.g. similar to "Decorator pattern is like glasses") - one reason I failed was that all MVC examples I could come up with were development related.

I once saw a list of pattern explanations but to the best of my memory MVC was not on it.

Thanks!

Solution 1

How about this - off the top of my head, hopefully it works for you.

MVC can be metaphorically related to a TV. You have various channels, with different information on them supplied by your cable provider (the model). The TV screen displays these channels to you (the view). You pressing the buttons on the remote controls affects what you see and how you see it (the controller).

I was watching TV, so I got some inspiration from there!

Solution 2

I don't trust metaphors. But it's not hard to explain it:

• the Model is the part of the code that knows things
• the View is the part of the code that shows the things the Model knows
• the Controller is the part of the code that gets commands from the user and tells the View what to show and the Model what to know.

Solution 3

The best way I describe it would be:

• The Model is the data source. It's your database storage, it's the code needed to add/remove/update/change the information you warehouse.
• The View is the part the user sees and interacts with. An HTML page, an application window.
• The Controller is the code that marries the View to the Model. If you clicked a "Delete" button, it handles the business logic and rules (are you the authorized person to delete? is it a deletable record, etc).

The View doesn't need to know anything about the Model. The Model doesn't need to know anything about the View. The Controller is what marries the information source (Model) with the output (View).

Think of it in terms of video games. Way back when - there were tons of different video cards and how they worked. Games needed all kinds of code to talk to them. You had to choose what kind of card you had before you could play the game. Game developers had to create code for different video cards.

Along comes something like OpenGL or DirectX -- and it acted as the middle-layer between them. Game developers could write to the DirectX interface -- instead of different card's instruction sets. It freed game developers from having to know about the specific video card. It freed card makers to be able to design to the DirectX instruction set.

In this case - you playing the game is the View, DirectX is the Controller, and the Model is the video card.

Solution 4

M-V-C Think of it as: "Order Details (including Customer & Employee info)", "HTML/ASP Form (to display the OrderDetails)" and "Order details service class (having methods to SaveOrderDetails, GetOrderDetails etc.).

The Model (Data Class e.g. OrderDetails)

The data you want to Display

The Controller (Service class)

Knows about the Model (Order Details)
Has methods to manage the Model
And as such can be unit tested Its Single Responsibility is to manage the OrderDetails CRUD operations.
It knows NOTHING about the View

The View (ASP Page)

Displays the Model (OrderDetail's ViewData).
It has to know about the Model's structure so it can correctly display the data to the users on screen.
The View's structure (style, layout, HTML etc., locale) can be changed at anytime without it changing anything in the application's functionality.
And as such, many Views can display the same Model in many different ways.
In multi-tenant web applications, Customer specific Views can be stored in a database table and displayed based on Customer information

Solution 5

Tell "your grandma" that you are the model (you are doing the work), he is the controller (i.e., middle manager), and the view is like marketing, they get all the credit.

View more solutions

Comments

[gonzobrains]

@DVK The idea was to explain what MVC is in layman's terms. As for Apple's stock price, I guess you kind of proved my point.

[DVK]

This is entirely too technical for explaining to a non-developer.

[John Sonmez]

I can't help but notice you said you don't trust metaphors, but used them all throughout your explanation.

[John Sonmez]

Can code "know" things? Can code "show" things? Can a controller "tell" something?

[nullException]

these are not metaphors, just term simplifications. if you want, expand "knows" to "embodies the knowledge about" or, more precisely "implements the mechanisms that deals with"

[Jomar Sevillejo]

I am still learning MVC, this really enlightened me. This gave me a better picture and yes, my level of understanding on MVC is my grandma's.

[Julian]

It is a good metaphor but I would like to add that besides the screen the user sees, the remote controller is also part of the view. The view dictates the gui components and sends user interaction input to the controller. The controller interprets the user action, so in this metaphor that would be the electric components inside the television. The model is correct in the metephor.

[Rukshan]

A correct answer but , with a bad example. Your example proves the point about MVC but mislead how GPUs work though :) Let me fix that. DirectX is not written to support different instruction of different video cards. It's the cards that's built to support up to specific version of DirectX. DirectX defines the standards and video card hardware conforms to it. That's why we have new video card generations for new DirectX versions, not new DirectX version to support each newly released video cards. So yes you don't have to write for each card because they either support directx or opengl

[Sritam Jagadev]

the best explanation that i have ever heard