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.
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"?
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?
In the diagram in wikipedia, there is no arrow between view and controller. Is it correct?
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?