MVC (model-view-controller) - can it be explained

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!

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

Answer 2

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.

Answer 3

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.

Answer 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

Answer 5

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.