11

We are making a rather large Swing application which has to implement the MVC pattern. The application currently looks like this:

There are quite a few views. They are created in a hierarchical manner where one main view contains (and creates) several views which all contain their own set of sub-views, etc. Each of these views retrieve information from the model independently from the other views, by calling the models static methods when necessary.

There are also quite a few controllers which are all totally separated from each other. Each controller belongs to a view. Each view creates its own controller, and adds the controller as a listener to user input. The controllers receive events from the views and then modify the model through the models static methods. When the views dispatch events which do not affect the model, but only affect the views, the views take care of these events themselves - without informing the controllers about the events. That is, the controllers are totally unaware of the views, and the controllers purpose is only taking care of the manipulation of the model. |EDIT: the controllers are currently attachments to their views; they only contain logic for event-handling. That is, the controllers are not components themselves, and do not contain components. They are implemented in the same manner as the following example: MVC example |

The model in the application is very passive, and does not even have listeners (it represents a database). It receives updates from the controllers.

In this example, the views own the controllers. Would it be better in the general case if the controllers owned and created the views, and if one let the views be unaware of the controllers, instead of the opposite? In that case, why? How would this be designed? If not, is there a better design in which the controllers are still unaware of the views? Or perhaps, is the best design neither of them?

EDIT:

As stated in the Original MVC definition:

the line "The View takes responsibility for establishing this intercommunication..." seems to indicate that the view creates the controller, or at least has the initial reference to the controller, and not vice versa.

So this is at least a possible way to do it (it is a valid MVC pattern), but the main question remains; which is better, and how would the best design look like? Especially when dealing with many controllers that are closely related to their respecive views?

EDIT: Another example of a view which references a controller: Oracles example

Datoraki
  • 1,223
  • 13
  • 26

1 Answers1

7

As seen in this outline, the controller has the model and the view(s). Any sub-views are managed by the respective parent view. Sub-views may forward events to the parent as discussed here. There's a simple example here with more links.

Community
  • 1
  • 1
trashgod
  • 203,806
  • 29
  • 246
  • 1,045
  • Ok, so I assume the design would look like the following: All controllers are created in some main class. All controllers are added as listeners to the main view. The subviews would call parent.stateChanged(e); to forward the events. The main view would fire event changes and would use an EventListenerList (should the main view implement some interface?). The controllers would ignore the received events which didn't concern them (important: how would they know what to ignore?). Is this it? Thanks – Datoraki May 08 '11 at 15:40
  • No, the controller often listens to the view(s) and the view(s) always listen to the model. This [game](http://robotchase.sourceforge.net/) shows multiple views listening to one model. As discussed [here](http://stackoverflow.com/questions/3066590/gui-problem-after-rewriting-to-mvc/3072979#3072979), the actual observer mechanism is an implementation detail; several approaches are mentioned there. You may want to define your own `ApplicationEvent` analogous to `AWTEvent`. – trashgod May 08 '11 at 16:38
  • @trashgod _No, the controller often listens to the view(s) and the view(s) always listen to the model._. Sorry, but I don't see the difference between this and what I suggested in my previous comment? Do you mean that (as opposed to what I wrote) there should be only one controller? – Datoraki May 08 '11 at 16:50
  • Ah, I misunderstood; you're right about controller(s) listening to view(s). I've never needed more than one application controller; it may be nothing more than a panel of components, each having its own model and view, that affect the application model. If you need more than one controller, you might look at [`Action`](http://download.oracle.com/javase/tutorial/uiswing/misc/action.html) "to separate functionality and state from a component." – trashgod May 08 '11 at 17:32
  • @Trashgod in this application, as it is now, the controllers are not panels or extending or using any swing components. The controllers only contain the logic for manipulating the model. They receive events from their respective view, and behave accordingly. This is because the GUI has no clear distinction (in terms of panels or sections) of what parts are controls and not. So the controllers only act as event-handlers for the actions from the GUI which affect the model. If we placed all the controls in one controller, this one would become huge. – Datoraki May 08 '11 at 18:27
  • @trashgod ...continued... Also, since the respective controls are currently coupled with their views, this whole change would decrease the apps cohesion, wouldn't you say? Is the used pattern not a "real" MVC pattern perhaps? – Datoraki May 08 '11 at 18:28
  • @trashgod the same way that this examples controller is implemented, that is. [MVC example](http://www.leepoint.net/notes-java/GUI/structure/40mvc.html) – Datoraki May 08 '11 at 18:39
  • I think we are in agreement. Indeed, the [outline](http://stackoverflow.com/questions/2687345/java-mvc-how-to-divide-a-done-text-game-into-mvc/2687871#2687871) that I cited above was actually based on the [diagram](http://www.oracle.com/technetwork/articles/javase/index-142890.html) linked from the article you cited. In words, a controller _has-a_ view to which it listens. I agree that there can be more than one controller, as you have described them. – trashgod May 08 '11 at 19:39
  • @trashgod the article with the diagram really helped me! =) And also the article linked from that article: the original MVC definition [Original MVC definition](http://st-www.cs.illinois.edu/users/smarch/st-docs/mvc.html). Still, I am not sure how your design would look like for the case with many controllers? How would the controllers know which events to ignore? More importantly, why is it better, as you suggested, for the controllers to own the views and not the opposite? – Datoraki May 08 '11 at 23:51
  • A controller _has-a_ view is how I interpret the solid arrows representing association in the [diagram](http://en.wikipedia.org/wiki/Model-view-controller). A controller invokes a view's methods, not the converse. One versus many controllers is probably an implementation detail; either way works. The important thing is the loose coupling afforded by the observer pattern, represented by the dotted lines. – trashgod May 09 '11 at 03:37
  • @trashgod There are also different variations to the MVC model; like the one in [the link you posted](http://www.oracle.com/technetwork/articles/javase/index-142890.html): `public PropertiesViewPanel(DefaultController controller) { this.controller = controller; `. Here the view clearly has a reference to the controller. But the question is: which is better, why, and what does the best design look like? Why is your suggestion better than the one in the question? Hope I'm not being a pain =) – Datoraki May 09 '11 at 13:53
  • Not at all, but I'm not sure there's definitive answer. Better designers than I have wrestled with the problem. I see MVC more as a guiding principle than a formula. In the [example](http://www.leepoint.net/notes-java/GUI/structure/40mvc.html), the model is created and then passed to the `CalcView` constructor. Instantiation of the model without reference to a view is one test of the model's independence. That instantiation can be in the view; sorry if seemed to suggest otherwise. [Swing itself](http://java.sun.com/products/jfc/tsc/articles/architecture/#separable) is a good example. – trashgod May 09 '11 at 18:10