Hi Brad
Isn't the placement of the ChangeListeners in the View a judgement call (some of the samples of MVC I have seen include it in the view, some include it in the controller) ?
I have also seen examples where the programmer has not had any link between the model and the view. However whenever I have found documentation describing the concept of MVC, it invariably states that there is a link between the model and the view.
The "Design Patterns" book (GOF) describes the link as: "
MVC decouples views and models by establishing a subscribe/notify protocol between them. A view must ensure that its appearance reflects the state of the model. Whenever the model's data changes, the model notifies views that depend on it. In response, each view gets an opportunity to update itself. This approach lets you attach multiple views to a model to provide different presentations. You can also create new views for a model without rewriting it.".
The
Sun MVC Blueprint shows that the model "
Notifies views of changes", and describes two ways this can be achieved: "
This can be achieved by using a push model, where the view registers itself with the model for change notifications, or a pull model, where the view is responsible for calling the model when it needs to retrieve the most current data".
There is an analogy of MVC in a book I am reading at present (which I won't name because I cannot recommend it). The analogy is that the MVC is
"like an Automobile. The speed of the car is affected by the accelerator pedal (Controller), the speed is shown by the speedometer (View) and the speed is manifested by the engines (Model).". If you think about it like that, the change in speed is not passed from the accelerator (controller) to the spedometer (view).
What is the advantage of placing the ChangeListeners in the View
Turn the question around: what is the advantage of having changes go through the controller? There may be times when you can find a reason for doing that, but normally you would not. The controller is only concerned with handling actions and events. It normally doesn't have to do anything with the data itself.
Normally all the work
on the data is performed by the model. All the work
displaying the data is done by the view. It makes sense for the model to automatically notify views if the data they are meant to be displaying has changed.
By the way: a model may have more than one controller and view attached to it. So something action performed in "view A" may change the data currently being modeled, which would have to be updated in "view B". The model is going to need some way of notifying affected classes that the data has changed. So you are going to have to register classes that are interested in observing changes with the model. Since you have to register anyway, why not have the view doing the registration?
(If you do place the ChangeListeners in the View, you need a reference to the Model inside the View, in order to add the ChangeListener to the Model's list of ChangeListeners) ?
Again: look at the Observer interface and the Observable class.
If the view implements Observer, then the controller can create an instance of the view, then register that instance with the model's Observable methods. (This is using push model). The view itself does not need to have any knowledge of the model at all - it is simply receiving data through it's update() method. Of course, if you decide to use the pull method, or if you decide to allow views to access static data in the model directly (such as your database schema for instance) then your view would need to have a reference to the model (or to an interface that the model implements).
Regards, Andrew