19

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: enter image description here

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

enter image description here

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?

pentanol
  • 133
  • 7
Aviv Cohn
  • 21,190
  • 31
  • 118
  • 178
  • 1
    2 answers, both upvoted, one says "interact with the view" the other says "interact with the controller".... makes me think MVC is not quite good an architecture if its this confused at such a fundamental level! – gbjbaanb Mar 29 '14 at 19:55
  • See also, on StackOverflow, [Should sorting logic be placed in the model, the view, or the controller?](http://stackoverflow.com/questions/11969964/should-sorting-logic-be-placed-in-the-model-the-view-or-the-controller/) – Izkata Mar 30 '14 at 00:09
  • https://www.visual-paradigm.com/guide/uml-unified-modeling-language/what-is-model-view-control-mvc/ and http://www.cs.utsa.edu/~cs3443/mvc-example.html : May this helps you – AjayGohil Feb 22 '21 at 04:01

3 Answers3

19

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.

  • A model notifies its associated view/views and controllers when there has been a change in its state. This notification allows views to update their presentation, and the controllers to change the available set of commands. In some cases an MVC implementation might instead be "passive," so that other components must poll the model for updates rather than being notified.
  • A view is told by the controller all the information it needs for generating an output representation to the user. It can also provide generic mechanisms to inform the controller of user input.
  • A controller can send commands to the model to update the model's state (e.g., editing a document). It can also send commands to its associated view to change the view's presentation of the model (e.g., by scrolling through a document).

From Microsoft's Overview of MVC.

  • Models. Model objects are the parts of the application that implement the logic for the application's data domain. Often, model objects retrieve and store model state in a database. For example, a Product object might retrieve information from a database, operate on it, and then write updated information back to a Products table in a SQL Server database.

    In small applications, the model is often a conceptual separation instead of a physical one. For example, if the application only reads a dataset and sends it to the view, the application does not have a physical model layer and associated classes. In that case, the dataset takes on the role of a model object.

  • Views. Views are the components that display the application's user interface (UI). Typically, this UI is created from the model data. An example would be an edit view of a Products table that displays text boxes, drop-down lists, and check boxes based on the current state of a Product object.

  • Controllers. Controllers are the components that handle user interaction, work with the model, and ultimately select a view to render that displays UI. In an MVC application, the view only displays information; the controller handles and responds to user input and interaction. For example, the controller handles query-string values, and passes these values to the model, which in turn might use these values to query the database.

Adam Zuckerman
  • 3,715
  • 1
  • 19
  • 27
  • What if you don't have GUI for all the actions? What if you have only API implemented for some specific parts? Does that mean user sometimes interacts with the View and sometimes with the Controller directly? – Mahdi Mar 29 '14 at 09:29
  • 2
    From my perspective, no. The API takes the place of the view. – Adam Zuckerman Mar 29 '14 at 09:39
  • but the API could be a simple `url-routes`, placed in the `Controller`. I mean no View at all ... – Mahdi Mar 29 '14 at 10:58
  • 1
    @AdamZuckerman Thanks for answering. In the next comment I'll describe how I *think* a common MVC implementation works, please confirm if it's correct or not. Thanks – Aviv Cohn Mar 29 '14 at 13:48
  • **The View** is the GUI. The user makes actions on the View. The View reports these actions to the **Controller**. The Controller **interprets these actions to the appropriate method calls on the Model**. **The Model** handles these method calls, and if necessary **updates the View**. An example in the next comment: – Aviv Cohn Mar 29 '14 at 13:49
  • (1) The user presses the "Send" button on the GUI (the View). (2) The View doesn't know what that means, it only knows it happened. It leaves the job of figuring out what this button press means, to the Controller. So it reports the button press to the controller. (3) The Controller is notified by the View about the button press. It interprets it to some meaning, and manipulates the Model accordingly. For example: View to Controller > "Button `send` pressed". Controller to Model > "Send data". Model handles what the Controller told it to do, and possibly tells the View to update accordingly. – Aviv Cohn Mar 29 '14 at 13:52
  • Views recognize user gestures and translate them to controller actions. Think of Siri on the iPhone or the Kinect on the Xbox. Of course, clicking a button in the GUI is a gesture, too, albeit very easy to recognize. – Fuhrmanator Mar 29 '14 at 18:02
  • 3
    @Mahdi An API, by definition, is there as a *programming* interface, not a *user* interface. Programs interact with the API, users interact with the View. – Eric King Mar 29 '14 at 21:27
  • @Prog I agree with your assessment of the View. Not so much with the rest of it. The Model does not update the View at all. That is handled by the Controller. When the Controller updates the Model, it determines if changes need to occur to the View. – Adam Zuckerman Mar 29 '14 at 23:02
  • Okay, so apart from the part about the Model possibly updating the View: Is everything else I wrote correct? About the 'flow' of actions? (View gets action from user > tells Control > Control interprets the action and updates Model) – Aviv Cohn Mar 29 '14 at 23:24
  • Yes. With the reverse also being true. I have updated my answer. Please let me know if that helps to make it any clearer. – Adam Zuckerman Mar 29 '14 at 23:28
  • Okay. According to the book I'm reading, MVC is a combination of patterns: Strategy, Observer and Composite. Composite is only inside the View GUI so that isn't relevant. I have questions regarding Strategy and Observer. Firstly, I know View and Controller make an instance of the Strategy pattern. But which object is the 'context' and which is the strategy? According to my book, the Controller is the Strategy for the View. The View can choose other controllers (Strategies) and replace them dynamically. But some people say that the View is the Strategy of the Controller. Which one do you agree? – Aviv Cohn Mar 29 '14 at 23:33
  • Secondly, regarding Observer: I know the Model is the Observable ('Publisher'). But which is the Observer? The View, the Model, or both? Thanks for your help – Aviv Cohn Mar 29 '14 at 23:34
  • That would make a very good (separate) question! – Adam Zuckerman Mar 29 '14 at 23:35
  • Very well :) Anyhow, would you say that the concrete design details of the MVC differ from programmer to programmer? Or does the MVC have very clear 'rules' as to what is happening? I've seen lots of versions of the MVC. Some claim the View and Model interact strictly through the Controller, others claim the View gets it's details directly from the Model. And other variations. Is the MVC something with clear design-rules - and there are lots of wrong people? Or is it rather subjective? – Aviv Cohn Mar 29 '14 at 23:40
  • I think that the implementation will have a lot to do with how the pieces interact. Madhi is correct though about the View never interacting directly with the Model. It would violate the Separation of Concerns. – Adam Zuckerman Mar 29 '14 at 23:44
  • I'm rereading the MVC chapter in Head First. According to that book, the View registers as an Observer to the Model, so it gets notified by the Model when the Model's state changes, so the View can change accordingly. Does this violate Seperation of Concerns? – Aviv Cohn Mar 29 '14 at 23:46
  • Meaning - the View talks to the Model only when the Model tells it to, through the Observer pattern (in 'Pull' style. The Model tells view that it changed, and View queries the Model in response). – Aviv Cohn Mar 29 '14 at 23:50
  • Absolutely. The View registering as an observer of the Controller would not. This may be an implementation variation that would not be considered appropriate by the definition of MVC. This may become an acceptable practice in the future. – Adam Zuckerman Mar 29 '14 at 23:51
  • @Mahdi When implementing something like a REST API, the part of the code that takes the URL/POST data and calls other functions is the View. The other functions being called should be the Controller (or part of it). Think of it this way: The Controller shouldn't be doing the grunt work of interpreting what the user (which isn't necessarily a human) intends. – Izkata Mar 29 '14 at 23:57
  • @Prog After talking with another developer this morning, he reminded me that when the View talks directly to the Model, you are starting to get into the MVVM model, not fully, but close. – Adam Zuckerman Mar 31 '14 at 16:37
  • Reminder: Please take extended comment threads to chat. I have created a [room](http://chat.stackexchange.com/rooms/13818/discussion-for-model-view-controller-does-the-user-interact-with-the-view-or-wi) for continued discussion. –  Mar 31 '14 at 18:33
7

The user interacts with the Controller. From the technical point-of-view you're not interacting with the View, you're just using it to interact with the Controller.

On the surface it seems that the user is interacting with the GUI -- also to a non-programmer this makes more sense, however by clicking on a button you're basically talking to the Controller not the View.

Also not all the applications -- even MVC web-applications, does have a GUI. You might interact with the Controller via an API -- just simple url-routes for example, placed in the Controller itself.

The Controller should be the place that Receives and Handles the user requests. So if you're somehow accessing the Model directly from View -- doesn't matter how, then it's not MVC anymore.

Mahdi
  • 1,983
  • 2
  • 15
  • 25
  • What I learned is basically this: The View is the GUI. The user makes actions on the GUI. When he/she does, the View (the GUI) reports to the Controller. The Controller than understands what these actions mean, and manipulates the Model accordingly. For example, the user clicked a 'Send' button on the GUI (the View). The View reports this to the Controller (View to Controller: 'The user pressed 'Send'). The Controller recieves the message and translates it to actions on the Model. (View to Controller: "The user pressed 'Send'". Controller to Model: "Send the data"). Is this correct? – Aviv Cohn Mar 29 '14 at 13:44
  • 3
    +1 This is correct. Things like menus and toolbars are part of the GUI but not part of the view, and go straight to the controller. Keystrokes likewise. – david.pfx Mar 29 '14 at 13:45
  • In a shorter version, here's how I think MVC works, please confirm if true or not: (1) The View (GUI) recieves actions from the user. (2) The View reports these actions to the Controller. (3) The Controller translates these actions to method calls on the Model. (4) The Model handles these method calls, and maybe updates the View accordingly if necessary. – Aviv Cohn Mar 29 '14 at 13:47
  • @Prog Well, the GUI is NOT necessary at all, that's what I'm trying to say. Imagine that you're updating the sidebar per minute to show some ads, related products, whatever, then there is no user interaction with the GUI at all, so how would you explain it then? My point is you're interacting with the Controller. It could be via the View -- GUI, or directly from changing the URL in the address bar, etc. – Mahdi Mar 29 '14 at 16:34
  • 1
    The reason views exist as an abstraction is so we can substitute them easily when necessary. A controller for an app on various platforms can be the same, but the views have to recognize user gestures differently and translate them into controller operations. I disagree, therefore, that users interact directly with controllers. – Fuhrmanator Mar 29 '14 at 18:06
  • 1
    @Mahdi I would say that in that case, there's no user interaction at all, it's the view communicating with the controller programmatically. The only interactions that are initiated by the *user* are via the view. – Eric King Mar 29 '14 at 21:25
  • Just to be absolutely clear, I agree with you that the View should **never** have a direct interaction with the Model. I think where we disagree is that my perspective is from an implementation, not a definition. – Adam Zuckerman Mar 29 '14 at 23:40
  • 1
    @david.pfx Keystrokes can't go directly from a browser window to a Controller. – Adam Zuckerman Mar 29 '14 at 23:41
  • @AdamZuckerman: OP said nothing about browser. Keystrokes go from the keyboard, not from a window and yes, they can go directly to the controller (for example in a game with a render loop) or via a window. – david.pfx Mar 29 '14 at 23:58
  • -1, the Controller should not be interpreting the data in a GET or POST request. The View is the part of the code that requests are sent to - it handles interpreting that data, then passing along the commands to the Controller. The result is then returned from the Controller to the View, which constructs an appropriate HTTP response. – Izkata Mar 30 '14 at 00:06
  • 2
    @Izkata "The View is the part of the code that requests are sent to" -- Sorry but this is the worst thing I heard here. How is that even possible? Can you back it up by providing a reference in an article or book? – Mahdi Mar 30 '14 at 08:44
  • @Mahdi Just look at the other most-upvoted answer. They're calling it the GUI, but UI or just "interface" is a better term. – Izkata Mar 30 '14 at 14:42
1

Let's use a concrete example of why users interact directly with views and not controllers.

In the music app on the iPhone, a high level feature is to play a playlist. "Play a playlist" is a function of a controller to the app.

There is more than one way to activate that function. I can click on the playlist inside of the app, or I can ask Siri (voice interface) to perform the same function. Those are two different gestures that are recognized by the various views.

The feedback in each view is also different. Siri will tell you that it is playing the music you requested. The music app will show you a visual feedback that it is playing the playlist.

Fuhrmanator
  • 1,435
  • 9
  • 19