Tell me more ×
Programmers Stack Exchange is a question and answer site for professional programmers interested in conceptual questions about software development. It's 100% free, no registration required.
up vote 63 down vote favorite
44

As a serious programmer, how do you answer the question What is MVC?

In my mind, MVC is sort of a nebulous topic — and because of that, if your audience is a learner, then you're free to describe it in general terms that are unlikely to be controversial.

However, if you are speaking to a knowledgeable audience, especially an interviewer, I have a hard time thinking of a direction to take that doesn't risk a reaction of "well that's not right!...". We all have different real-world experience, and I haven't truly met the same MVC implementation pattern twice.

Specifically, there seem to be disagreements regarding strictness, component definition, separation of parts (what piece fits where), etc.

So, how should I explain MVC in a way that is correct, concise, and uncontroversial?

share|improve this question
3  
Note: If you are working in ASP.NET, MVC has a second, non-nebulous meaning: ASP.NET MVC – Brian Oct 30 '12 at 17:18

10 Answers

up vote 65 down vote accepted

MVC is a software architecture - the structure of the system - that separates domain/application/business (whatever you prefer) logic from the rest of the user interface. It does this by separating the application into three parts: the model, the view, and the controller.

The model manages fundamental behaviors and data of the application. It can respond to requests for information, respond to instructions to change the state of its information, and even to notify observers in event-driven systems when information changes. This could be a database, or any number of data structures or storage systems. In short, it is the data and data-management of the application.

The view effectively provides the user interface element of the application. It'll render data from the model into a form that is suitable for the user interface.

The controller receives user input and makes calls to model objects and the view to perform appropriate actions.

All in all, these three components work together to create the three basic components of MVC.

share|improve this answer
6  
+1 I really prefer to think of MVC as an architecture of three (or more) patterns, than a design pattern. There's no canonical implementation, it simply isn't that small, and all implementations will have quite a few more than the implied core components. – Yannis Rizos♦ Dec 30 '11 at 8:43
13  
Though this answer has 21 upvotes, I find the sentence "This could be a database, or any number of data structures or storage systems. (tl;dr : it's the data and data-management of the application)" horrible. The model is the pure business/domain logic. And this can and should be so much more than data management of an application. I also differentiate between domain logic and application logic. A controller should not ever contain business/domain logic or talk to a database directly. – Falcon Dec 31 '11 at 13:58
1  
I cannot disagree more with this answer simply because it claims mvc to be rational outside the presentation layer. The rest of the answer is ok. MVC should start and end at your presentation layer and absolutely should not have your business logic and repository in it. Doing so effectively places your entire application in your presentation layer and makes no available API which would allow direct access to your business logic or pure data without it being designed for the originating app. This is not open for extensibility, view models get you closer but you're still missing loose coupling – Jimmy Hoffa Oct 21 '12 at 18:46
1  
@Jimmy: In many constructions of MVC, the models can be reused in APIs because they do not have dependencies on the UI -- the separation between view and model takes care of that. But that depends, of course, on how you choose to define 'model'. If you are going to make a judgment about MVC, you should first explain which interpretation of MVC you are using. – Owen S. Jan 5 at 22:13
1  
@Yannis: This just begs the question: What is an architecture of patterns? Why wouldn't you call that just another design pattern? The very definition of design pattern in GoF (and Alexander) makes it quite clear that patterns ought not prescribe one canonical implementation (though the popularity of both books undercuts that notion a bit). – Owen S. Jan 5 at 22:19
show 3 more comments
up vote 36 down vote

MVC is mostly a buzzword.

It used to be considered a pattern, but its original 1979 definition has been dumbed-down, passed-on, misinterpreted, taken out-of-original-context. It's been ill-redefined to the point it starts resembling a religion, and while this certainly helps its cargo cultists defending it, its name doesn't associate anymore with a solid set of guidelines. As such, it cannot really be considered a pattern anymore.

MVC was never meant to describe web applications.
Nor modern operating systems nor languages.
(some of whom actually made the 1979 definition redundant)

It was made to. And it didn't work out.

We now deal with an obscene web-mvc hybrid that, with its awful buzzword status, ill definition, and having semi-illiterate-programmers as a target demographic, makes a really bad publicity to software patterns in general.

MVC, thus, became separation of concerns distilled for people who don't really want to think too much about it.

  • The data model is handled one way,
  • the view in another,
  • the rest is just named "controller" and left to the reader's discretion.

Web sites / web applications in the '90s did not really use to apply separation of concerns.

They were horrible botches of intermixed spaghetti code.
UI changes, redesigns, and data rearrangements were incredibly hard, expensive, long, depressing, ill-fated.

Web technologies like ASP, JSP and PHP make it too easy to intermix view concerns with data, and application concerns. Newcomers to the field usually emit inextricable code mudballs like in those old times.

Thus, a growing number of people started repeating "use MVC" in endless loops on support forums. The number of people expanded to the point of including managers and marketers, (to some the term was already familiar, from those times in gui progrmming, in which the pattern made sense) and that became the behemoth of a buzzword we have to face now.

As it stands it's common sense, not a methodology.
It's a starting point, not a solution.
It's like telling people to breathe air, or make crunches, not a cure for cancer.

share|improve this answer
8  
It's certainly not mostly a buzzword. It's true that MVC tends to be more pervasive and less distinct than other design patterns, so you might think of it as an organizing principle or paradigm instead. But whatever you call it, it's a fundamental concept in a number of very successful object oriented frameworks. To pretend that it's just a buzzword, i.e. a fashionable phrase that doesn't mean much, is to do a disservice to the OP. – Caleb Dec 30 '11 at 6:28
11  
It's a fancy word for pre-existing concepts that didn't really need one. And what design pattern / architecture doesn't fit that description? – Yannis Rizos♦ Dec 30 '11 at 12:30
7  
+1 Frankly most of this stuff is obvious once you have a grasp of the fundamentals (cohesion, coupling, readability, orthoganality, etc.) and combine that with capabilities of modern languages. – lorean Dec 30 '11 at 19:24
7  
The data model is handled one way, the view in another, the rest is just named "controller" +1 – c69 May 2 '12 at 19:02
6  
-1. I wish I could -10 for all of the idiotic +1 comments. How is any of this "obvious" given the basic principles of coupling and cohesion? UI architectures abound, including MVC, MVP, MVVM, Forms, and Smalltalk's model. Some companies also push the Composite Application architecture to the extreme, such as in WS-CAF. To say that "common sense" automatically leads you to MVC holds about as much water as Descartes' so-called proof of God. It's obviously what you know, but your answer demonstrates either an ignorance of other methods or an inability to expand your own horizons. – Aaronaught Oct 21 '12 at 16:35
show 14 more comments
up vote 20 down vote

I explained MVC to my Dad like this:

Imagine a photographer with his camera in a studio. A customer asks him to take a photo of a box.

The box is the model, the photographer is the controller and the camera is the view.

Because the box does not know about the camera or the photographer, it is completely independent. The photographer can walk around the box and point the camera at any angle to get the shot/view that he wants.

Non-MVC architectures tend to be tightly integrated together. If the box, the controller and the camera were one-and-the-same-object then, we would have to pull apart and then re-build both the box and the camera each time we wanted to get a new view. Also, taking the photo would always be like trying to take a self-portrait - and that's not always very easy.

share|improve this answer
1  
+1 I quite like that analogy – dreza Nov 18 '12 at 19:38
Thank you dreza. – JW01 Dec 2 '12 at 15:26
up vote 7 down vote

MVC is a design pattern used to isolate business logic from presentation.

It differs from a lot of other design patterns by the fact that it usually isn't implemented succinctly, but is the base of a framework.

While an application implementing a Strategy pattern is just a small detail about it, saying that a web app uses the MVC design pattern is very defining of its architecture.

share|improve this answer
2  
That's not strictly helpful, there are very specific requirements to implement the MVC pattern which make it differ from MVP, MP, MVVM. It also has a different target audience to those other presentation patterns. – Ian Dec 30 '11 at 12:43
up vote 3 down vote

MVC is a software design that separates the following components of a system or subsystem:

  1. Model - Data about the state of the application or its components. May include routines for modification or access.
  2. View - An interpretation of the data (model). This is only limited to a visual representation, but could be audio, derived information (e.g. statistics piped into another model object), etc. Furthermore, a single model may have multiple views.
  3. Control - Handles external input to the system invoking modifications on the model. The control/view may be closely related (in the case of a UI). However, other external input (such as network commands), may be processed which are completely independent of the view.
share|improve this answer
up vote 2 down vote

I would say MVC is a concept or a family of similar patterns.

I think this article is worth to read. GUI Architectures by Martin Fowler

share|improve this answer
3  
That Fowler article is excellent, and everyone who uses the term MVC should read it. Two points I find particularly interesting are that the original use of the term MVC in GUIs is rather different to the use in web frameworks, and that in GUIs, the separation between view and controller was found to be less useful than anticipated. – Tom Anderson Oct 21 '12 at 22:38
up vote 1 down vote

First, you have to determine who the asker of the question is, and what sort of answer he's looking for. You respond to this question with another question, such as "In what sense?"

You can ask if they are referring to MVC in general, a particular implementation of MVC (ie asp.net MVC, spring MVC, smalltalk MVC, etc..), what it is technically, what it is philisophically (yes, it has a philosophy as well), etc..

If this is a question on a test, and you can't ask the asker to clarify, then you will have to guess based on the context.

A good, simple answer is:

MVC is a software user interface architecture used to seperate structural and behavioral concerns in order to facilitate more maintainable sofware.

You can also say:

By seperating the View from the Controller from the Model, it encourages isolation of components based on their responsibilities. In theory, and usually in practice, this helps to improve maintainability by preventing the different parts of the system from co-mingling and creating more complex systems.

But, in the end, you will be judged on whether you give the answr they are expecting. The only solution to the problem is find out what kind of answer they are expecting.

share|improve this answer
up vote 0 down vote

I always start off by telling them that the pattern is not anything new and has been around for many years... its at this point they give me an inquisitive look and BAM!, they are hooked:

And then I would pretty much talk about the various points like the previous answers, but I think its important to be contextual as well, as JB King said, ASP.NET MVC etc,

share|improve this answer
up vote -1 down vote

The term MVC only comes up when we are deciding on a framework for our next project. Having worked in startups where the term MVC is pervasive, I answer the inquiries of my collegues thusly:

  • There is the ORM (hibernate, ActiveRecord, LinqToSql, axon, etc.). Model classes (entity objects) are mapped to data tables and relations. They also provide non-trivial queries (such as outer joins and aggregations) made from those tables.

  • There is the controller which is responsible for Actor-Data interaction. Controller classes provide all the actions which the actors can do.

  • There is the view which is an Actor's interface to the controller. View decides what to show based on what controllers provide and the method of input from the Actor.

People who have read and understood "object oriented design" books [citation needed] immediately get the idea, since they are familiar with terms such as entity and actor.

share|improve this answer

Your Answer

 
discard

By posting your answer, you agree to the privacy policy and terms of service.

Not the answer you're looking for? Browse other questions tagged or ask your own question.