How does controller work with view in MVC?

Question

Link says

MVC – Model View Controller

Let’s look at MVC first. You’ll notice a few things about the diagram:

The input is directed at the Controller first, not the view. That input might be coming from a user interacting with a page, but it could also be from simply entering a specific url into a browser. In either case, its a Controller that is interfaced with to kick off some functionality.

There is a many-to-one relationship between the Controller and the View. That’s because a single controller may select different views to be rendered based on the operation being executed.

Note the one way arrow from Controller to View. This is because the View doesn’t have any knowledge of or reference to the controller.

The Controller does pass back the Model, so there is knowledge between the View and the expected Model being passed into it, but not the Controller serving it up.

1. What does the last sentence mean? Specifically, what do the three clauses mean:

   • "The Controller does pass back the Model"

   • "there is knowledge between the View and the expected Model being passed into it"

   • "not the Controller serving it up"?

2. There is an arrow from model to view, which means that whenever model's state changes, view will automatically update itself. This is not done via controller. So why do we need an arrow (one-to-many relationship) from controller to view?

3. In the diagram in wikipedia, there is no arrow between view and controller. Is it correct?

   

4. In Design Patterns by Gang of Four

MVC also lets you change the way a view responds to user input without changing its visual presentation. You might want to change the way it responds to the keyboard, for example, or have it use a pop-up menu instead of command keys. MVC encapsulates the response mechanism in a Controller object. There is a class hierarchy of controllers, making it easy to create a new controller as a variation on an existing one.

A view uses an instance of a Controller subclass to implement a particular response strategy; to implement a different strategy, simply replace the instance with a different kind of controller. It's even possible to change a view's controller at run-time to let the view change the way it responds to user input. For example, a view can be disabled so that it doesn't accept input simply by giving it a controller that ignores input events.

Does the book mean that there is interaction directly between view and controller?

Thanks.

Answer 1

1) I suspect it is simply the style which is not as clear as it could:

There is knowledge between the View and the expected Model being passed into it

The view knows the model (in fact there is an arrow missing in the schema). In general it is injected into the view at construction:

• The view can query the model if needed
• The view can subscribe as an observer to the model

not the Controller serving it up

This sentence underlines the difference with MVP and MVVP where the view accesses the model indirectly. In MVC, the controller does not play the role of middle-man to "serve the information to the view": the view has to care for itself and get the information directly from the model

The Controller does pass back the Model

This is not fully clear. I suppose it is meant that the controller injects the model into the view. There is only one controller, and the idea is that if more views are needed, it's on request of the user; so the controller launches their construction.

2) Controller and views

As said above, there is only one controller, and mostly, the controller creates the views. Regardless of how the views are created, the controller must know them. Because the user may want to close a view, or may want to instruct the view of some viewing parameters (e.g. filter some information). Therefore, the controller must know the view to communicate with it.

3) WIkipedia diagram

Wikipedia references the original article about MVC, in which the link between the controller and the view are clearly documented.

The diagram is simplified and meant to explain the responsibilities and main flow of information.

4) MVC and GoF

MVC is a very old concept that dates back to the end of the 70s, when GUIs were something quite rare and exotic. Since then Windows (and other GUI platforms) changed considerably the perceptions.

GoF was written in the middle of the 90s, and is of course influenced by this evolution. The most important difference is the way user input is processed in reality: the views are nowadays generally implemented as windows that have their own menus, and user input processing. And this is what the text is about: views are in GoF considered as the prime user-input, and this input is then passed to the controller.

Furthermore, GoF does not consider MVC as a pattern but a combination of patterns. They therefore map MVC to their own patterns. This is expecially visible for the controller, where GoF considers several controller instances for a view. This is a variation of the original MVC pattern

Conclusion

If you browse on MVC articles, you will find many variants. There are even articles that describe MVC variants that are in reality MVP. But this confusion is not without reason: it's a symptom that the original MVC does no longer fit the current GUI reality. Don't misunderstand me: it's a brilliant architecture and a very valid separation of concerns. But the split of responsibilities between view and controller needs a little more flexibility.