Relationship between Model, View and Controller

[Liang Anmian]

Hi there,

I know that there are numurous topics on MVC. I've searched the forum, but cannot find what I want, so I got to create a new topic.

What is the relationship between the 3 components? Relationship as in, which component maintains a reference to which component? For instance, should Controller maintain references to all the Views (I intend to support multiple views), as well as the Model? Should Model maintain references to all the Views too? Should all Views maintain a reference to Model? Up to now I'm still very confused about the relationship. I have a couple more of questions:

1) Business methods should be in the Model, not the Controller, right?

2) Table model is actually inside the View, not the Model, right, since such models are view-dependant? For instance, Table model can only be used by JTable.

3) Is it possible to implement MVC in such a way that it satisfies the following:

i) Views never have to query the Model for data. In other words, Model will automatically update Views.

ii) Views cannot change Model.

Sorry for asking so many questions at one go, but I find MVC a very confusing and challenging topic to tackle.

[Frans Janssen]

Hi Liang,

1) Business methods should be in the Model, not the Controller, right?

Right.

2) Table model is actually inside the View, not the Model, right, since such models are view-dependant? For instance, Table model can only be used by JTable.

Also right. Sun have used MVC-terminology for single components (as opposed to your whole application design), which may be confusing at times. Although you could create another component/view that uses TableModel as its model, TableModel in general cannot function as THE model in your MVC architecture.

3) Is it possible to implement MVC in such a way that it satisfies the following:

i) Views never have to query the Model for data. In other words, Model will automatically update Views.

Yes, that is possible. You should use the Listener or Observer patterns for this, so that the Model does not really know which views exist. It only knows it has a list of registered listeners/observers that it has to notify on significant events.

The Model must never call any methods in the views directly, because then you would be implementing the MVC pattern upside down!

ii) Views cannot change Model.

In general views should not change the model, because why would that be necessary for viewing? The controller is the one that will make changes to the model.

Frans.
[ April 24, 2005: Message edited by: Frans Janssen ]

[Liang Anmian]

Thanks a lot for the answers. They are very helpful. So my final clarification for MVC. According to your reply, I assume that the following is the relationship.

i) Controller maintains a reference to both Model and all Views.

ii) Model maintains a list of Views. All Views implement a certain interface, and Model should only call the methods in the interface. In other words, observer pattern is utilized so that the Model does not need to know how the Views work. It only needs to know how to notify the Views.

iii) Views do not maintain a reference to the Model in order to prevent the Model from being changed by the Views. The driver class will manually register the Views with the Model.

iv) Views need a reference to the Controller, so that it can register listeners.

Am I correct?
[ April 24, 2005: Message edited by: Liang Anmian ]

[Frans Janssen]

i + ii: correct

iii: also correct, but personally I would prefer that the views register themselves with the model, instead of a third party class doing that. But that's probably just a matter of taste.

iv: I don't agree with this. The views should be unaware of the controller(s) in the same sense that the model must be unaware of the views. If the views must change due to controller actions, the controller must call the views directly.

Frans.

[Liang Anmian]

If that's the case, how do you register listeners to the various components, such as buttons? Do you provide acceessor methods for the components, and register listeners directly inside the controller constructor? For example:

tableView.getSearchButton().addActionListener(this);

Is this how you implement it?

[Frans Janssen]

No, in MVC it should be the other way around: the views are not listening for controller triggers, but the controller will notify the views and/or the model.

So something like this:

class ControllerButton extends JButton {
    ControllerButton(final View view) {
        addActionListener(new ActionListener(){
            view.someNotificationMethod();
        });
    }
}

Frans.

[Liang Anmian]

So what you are saying is, components that do not represent the Model are coded inside the controller? For instance, my view will ONLY contain a JTable and a table model, because they are showing the Model data. Other components like the search button, search textfields etc, which do not contribute to representing the Model data on the screen, are actually inside the controller and NOT inside any of the views?

Hopefully I'm correct this time round.
[ April 25, 2005: Message edited by: Liang Anmian ]

[Frans Janssen]

Originally posted by Liang Anmian:
So what you are saying is, components that do not represent the Model are coded inside the controller? For instance, my view will ONLY contain a JTable and a table model, because they are showing the Model data. Other components like the search button, search textfields etc, which do not contribute to representing the Model data on the screen, are actually inside the controller and NOT inside any of the views?

Yes, that's completely correct!

Frans.

[Liang Anmian]

Frans, thank you very, very much for your explanations. They are very clear and detailed. Finally I can start implementing the client GUI. Kudos to you!
[ April 25, 2005: Message edited by: Liang Anmian ]

[Frans Janssen]

Frans, thank you very, very much for your explanations. They are very clear and detailed. Finally I can start implementing the client GUI. Kudos to you!

No problem! I am glad I could help out!

Frans.

[David Sham]

I'm afaid I have to disagree with some of what was said so far on this topic. I'm a GUI/Swing developer and I use a lot of MVC. It is true that the Swing components use MVC, but what we are talking about here, as I understand it to be, is MVC2 - which is system wide use of MVC.

Using this design, the view can have references to the model and controller. But the model cannot have any references to the view. The model should know nothing about the view or controller. Business logic specific to the model should reside in the model. All other business logic should reside in the controller, or be delegated to other manager classes via the controller. The controller can have references to the view and model. In many cases it is necessary for the view to have a reference to the controller, so that the GUI components in the view can add the controller as the appropriate listener. GUI components for the view should not be built in the controller. The controller should have no knowledge of the GUI constructs (building of the GUI itself) of the view. The view can have a reference to the model directly, but never the opposite (model having a reference to the view). However, usually the view uses the controller to communicate with the model.

One of the main purposes of using MVC2 is to provide a clean separation between the model, view, and controller. In theory, the view for an application using MVC2 should be completely removeable or replaceable without any, or only minimal, disruption to the controller, and no disruption to the model. This means you should be able to swap out views at ease with MVC2 if designed correctly. Thanks.

[Frans Janssen]

Hi David,

Using this design, the view can have references to the model and controller.

I would disagree with this statement based on the way I learned MVC. However some Googling around teaches me that apparantly there are some flavours of MVC around which indeed allow this.

In many cases it is necessary for the view to have a reference to the controller, so that the GUI components in the view can add the controller as the appropriate listener.

There is no need for the view to have a reference to the controller to do that. The view could offer methods (like addActionListener, but preferably on a slightly higher abstraction level), that the controller can call to be notified of significant events in the view. Granted, the view will then have a reference to the controller in its event listener lists, but that will be an "anonymous" reference, that does not result in any strong coupling of view and controller.

With the parts of your message I didn't quote, I wholeheartedly agree!

Frans.

[David Sham]

Thanks for your input Frans. It's good to get other's thoughts to learn of different approaches. There may be different flavors of MVC around, indeed.

But how strict do you think Sun will be with MVC regarding this assignment? For example, my controller contains references to the view and model (only local model references). My view contains a reference to my controller and local model references. My model contains no references to view or controller.

In other words:
controller --> aggregates --> view
controller --> aggregates --> model (locally in different methods)
view --> aggregates --> controller
view --> aggregates --> model (locally in different methods)

Do you think I would get docked points for designing my MVC pattern this way? Thanks for any input.

[Frans Janssen]

Hi David,

But how strict do you think Sun will be with MVC regarding this assignment? For example, my controller contains references to the view and model (only local model references). My view contains a reference to my controller and local model references. My model contains no references to view or controller.

Personally I don't like it when two objects have mutual dependencies, which your view and controller now have. However, the UI is probably the part of software where it is hardest to avoid, because the UI objects are very closely coupled (even if you pretend they don't, like "my" MVC pattern does ).

If I am not mistaken Microsoft have a similar pattern called Document-View where the view encapsulates the MVC-view and controller, which proves that there is a need to tackle the interdependency of view and controller.

Do you think I would get docked points for designing my MVC pattern this way? Thanks for any input.

No, I don't think so. I think that the assessor will grade your design on its own merits and not on whether it exactly implements some pattern (and as we have established, the pattern does not even exist).

When I submitted my assignment, I had basically all UI behavior in one big monolithic class, assuming that simplicity could be a reason not to use a pattern, but I guess I was naive there, because I lost significant points on the UI-part. So I can at least tell you that that is not the way to go! :-)

Frans.

[Liang Anmian]

So the bottom line is, there is definitely more than 1 way to design the MVC architecture. No right and wrong here. Ultimately, it depends on how your application works.