If you've ever applied to a web development position, then you've probably been asked to define MVC.
My answer usually goes something like this:
- M is for model. That's your data layer. A model is a class that allows you to interact with the data source and perform CRUD operations. Most often the data source is a MySQL database, but ideally the framework will provide support for different types of data sources.
- V is for view. This is a type of UI layer. It's the page that is displayed to the end user.
- C is for controller. This is also a type of UI layer. It is responsible for receiving a request and returning a response. That is, it returns the appropriate view based on the path of the request (the URL to which the user navigated) and possibly input such as form data. It is considered a best practice to keep your controllers as lean as possible. So your controllers should be relatively devoid of business logic, which should be handled in its own layer. A common approach is to put business logic in "service" classes (e.g. SaleHandler).
Obviously I think this is a good definition, otherwise I wouldn't give it in an interview! It's not as concise as it could be, but an interviewer is probably looking for evidence that you have an experiential familiarity with the concepts, as opposed to a regurgitation of a textbook definition. To illustrate, consider the hyper-generalized definition offered by Wikipedia :
Model–view–controller (usually known as MVC) is a software design pattern commonly used for developing user interfaces that divide the related program logic into three interconnected elements. This is done to separate internal representations of information from the ways information is presented to and accepted from the user.
Is it technically correct? Sure, but it's so vague that anyone not already familiar with MVC will probably have trouble visualizing how it would actually be put into practice. It doesn't even describe the components. If you gave this definition in an interview, the interviewer would no doubt ask you to elaborate.
Lately I have been reading Design Patterns: Elements of Reusable Object-Oriented Software and in the introduction, the "Gang of Four" (as the authors are lovingly called) use MVC as an example to elucidate what they mean by the term "pattern." Here is their definition:
MVC consists of three kinds of objects. The Model is the application object, the View is its screen presentation, and the Controller defines the way the user interface reacts to user input. Before MVC, user interface designs tended to lump these objects together. MVC decouples them to increase flexibility and reuse.
It occurred to me that you could really impress an interviewer if you gave them a canonical definition of MVC. I thought it reasonable to assume that this book's definition of MVC is the canonical one, because it's basically The Bible of The Church of Object-Oriented Programming.
For bonus points, you could even describe the components and their relationships in terms of other design patterns:
The model communicates with its views when its values change, and the views communicate with the model to access these values... [This] design is applicable to a more general problem: decoupling objects so that changes to one can affect any number of others without requiring the changed object to know details of the others. This more general design is described by the Observer design pattern...
MVC supports nested views with the CompositeView class, a subclass of View. CompositeView objects act just like View objects; a composite view can be used wherever a view can be used, but it also contains and manages nested views... [This] design is applicable to a more general problem, which occurs whenever we want to group objects and treat the group like an individual object. This more general design is described by the Composite design pattern...
A view uses an instance of a Controller subclass to impelement a particular response strategy; to implement a different strategy, simply replace the insance with a different kind of controller... The View-Controller relationship is an example of the Strategy design pattern...
MVC uses other design patterns, such a Factory Method to specify the default controller class for a view and Decorator to add scrolling to a view. But the main relationships in MVC are given by the Observer, Composite, and Strategy design patterns.
But have we arrived at a canonical definition? I did some digging and it turns out that Design Patterns, written in 1994, is not the first publication to define MVC.
Wikipedia has this to say about the history of MVC:
One of the seminal insights in the early development of graphical user interfaces, MVC became one of the first approaches to describe and implement software constructs in terms of their responsibilities. Trygve Reenskaug introduced MVC into Smalltalk-79 while visiting the Xerox Palo Alto Research Center (PARC) in the 1970s. In the 1980s, Jim Althoff and others implemented a version of MVC for the Smalltalk-80 class library. Only later did a 1988 article in The Journal of Object Technology (JOT) express MVC as a general concept.
This would seem to suggest that the first written publication to define MVC is that 1988 article in the Journal of Object Technology , which says this:
Model-View-Controller (MVC) programming is the application of [a] three-way factoring, whereby objects of different classes take over the operations related to the application domain (the model), the display of the application's state (the view), and the user interaction with the model and the view (the controller).
However, upon even further digging (i.e. going to the sources used by the Wikipedia article), I discovered that there is a publicly available note by Trygve Reenskaug (the Nowegian computer scientist whom Wikipedia seems to credit as the inventor of MVC) dating back to 1979! In December of that year, he wrote:
Models represent knowledge. A model could be a single object (rather uninteresting), or it could be some structure of objects...
A view is a (visual) representation of its model. It would ordinarily highlight certain attributes of the model and suppress others. It is thus acting as a presentation filter...
A controller is the link between a user and the system. It provides the user with input by arranging for relevant views to present themselves in appropriate places on the screen. It provides means for user output by presenting the user with menus or other means of giving commands and data. The controller receives such user output, translates it into the appropriate messages and passes these messages on to one or more of the views.
But wait, there's more! On one of his pages hosted by the University of Oslo , Reenskaug writes that "the hardest part was to hit upon good names for the different architectural components." Before he arrived at "Models-Views-Controllers," he was calling it "Thing-Model-View-Editor." In a note from May 1979 , Reenskaug describes this prototype of MVC architecture:
[A Thing is] something that is of interest to the user. It could be concrete, like a house or an integrated circuit. It could be abstract, like a new idea or opinions about a paper. It could be a whole, like a computer, or a part, like a circuit element...
A Model is an active representation of an abstraction in the form of data in a computing system...
To any given Model there is attached one or more Views, each View being capable of showing one or more pictorial representations of the Model on the screen and on hardcopy. A View is also able to perform such operations upon the Model that are reasonably associated with that View...
An Editor is an interface between a user and one or more views. It provides the user with a suitable command system, for example in the form of menus that may change dynamically according to the current context. It provides the Views with the necessary coordination and command messages...
So, have we arrived at the canonical definition? I will leave that for the reader to decide. I think we have probably arrived at the earliest definition ever given, but whether that is the best candidate for the definition is up for debate. Regardless, I hope you have learned as much reading this post as I did writing it. Next time I'm asked to define MVC, I'll be able to get even more pedantic than usual!
Now I just have to figure out how to pronounce Trygve Reenskaug...