I have recently learned about the MVC design pattern. I'm learning from the Head First Design Pattern book.
According to this book (if I understand correctly):
The Model is most of the application logic and data.
The View is basically the GUI that represents the Model visually to the user.
The Controller is responsible to 'mediate', and act as a 'middleman' between the View and the Model. The View reports to the Controller that the user made an action, and the Controller translates it to method calls on the Model. The following figure shows what is described above:
However, a lot of places on the web contradict what I understand from that book. They claim that generally the user interacts with the Controller, not the View. The following figure illustrates the contradiction
Which one is true or more common? Does the user interact with the Controller directly, or with the View directly? Are both approaches acceptable? Which is more common?
Best Answer
The user interacts with the View, but the View must communicate the actions to the Controller. The Controller may update the Model, but it isn't required with every/any change.
The description I am providing is based on my personal experience with the .NET implementation of MVC. Your implementation can be different.
The Controller is where actions are processed, basically a business layer. A simple controller will do nothing more than get the data from the Model to feed to the View. A complicated Controller will perform all sorts of actions, up to security management, authentication, authorization, registration, and possibly many other things.
The View should only be responsible for displaying the information in a fashion that the user can understand. There can be some cross over here with both the Controller and the Model as things like Single Page Applications (SPAs) will have data validation feedback for the user. Any other cross overs are heavily frowned upon.
The Model deals with data. This includes validation of data (where applicable). Data storage and retrieval is also handled in this layer.
UPDATE
There seems to be some confusion surrounding who does what when. I included two different overviews of the MVC architectures because they are similar, but not the same. There is room for either interpretation. Possibly, many more. The descriptions above are my interpretation of MVC from multiple sources, including my own experience building applications using this methodology. Hopefully, this update will help to clear up some of this confusion.
MVC is an attempt to build a Separation of Concerns design pattern for software development. It has primarily been implemented in web based applications (to my knowledge).
The View handles all of the user interaction. If your user clicks on a button, the View determines if the click is a user interface interaction or something that is beyond its concern (a Controller interaction). If the button does something like copy values from one field to another, your implementation will determine if that is a View concern or a Controller concern. You will most likely only have this blurring of concerns when dealing with a Single Page Application (SPA).
The Controller is where your actions are processed. The View has communicated the user decided to change values for some fields. The Controller may perform validation on that data or it may be handled by the Model. Again this is implementation dependent. If the Controller has security features, it may determine that the user doesn't have sufficient privileges to perform the action. It would reject the changes and update the View accordingly. The Controller also determines what data to retrieve from the Model, how to package it, and update the View with that data.
The Model determines how and where to store data. It may also perform validation of that data before storing it (it should do this because people will bypass the View on occasion).
Wikipedia has an article on MVC.
From Microsoft's Overview of MVC.