MVC Controller for each Frame/Window ?
I am looking into to refactor some existing enterprise applications into the MVC or MVP framework. One of my main questions is the following. Do you need to create a Controller interface/implementation for each root UI component you build. Lets say I have a window that opens up that contains a list of data in a table . Do I need to create a Controller for that component as well. Basically is MVC with swing a 1 to 1 thing? Let me know if I didn't make any sense I will clarify as much as possible.
[508 byte] By [
sloanCBa] at [2007-10-3 4:05:53]
Hi,
One powerful design technique is to structure your GUI so that it uses a hierarchy MVC. Basically, you have a controller for the main application window, and then each separate dialog, internal frame, or other significant component has it's own custom controller. Those sub-controllers will sometimes delegate events 'upward' to their parent controller when they don't know how to handle an event. Here, I'm just throwing around the term event meaning anything you need to do in response to user interaction.
The advantage of using a hierarchy MVC is reuse. It is way more complicated to write your code with lots of models, views, and controllers, but you get the advantage of reuse.
Think about it this way: If you have a window with a tabbed pane with a bunch of stuff going on in each tab, how can you reuse or show one of those tabs somewhere else in the GUI in a completely separate dialog?
The way to accomplish reuse of the tab is to code the tab (a JComponent (view)) with it's own custom model & controller which do not depend on anything else. Then it is easy to reuse that tab elsewhere. The way you break the dependencies on other parts of that window is to make the controller for that individual tab 'delegate' events upward. For example, the user selects a check box in the tab,and another part of the GUI (outside the tab) needs to know about it. Normally you would need a reference to the other part of the GUI in the tab, so when the tab's checkbox is selected it can update the other component (which is outside the tab). The way you avoid this dependency is to structure the controller for that tab so that it sends an event to it's parent controller, who then decides to ignore it, or knows to update another part of the GUI. That way, that one tab is not directly updating another part of the GUI and you have no dependencies there that would otherwise hinder reuse of that tab elsewhere.
So there is a trade off, if you think something will be reused, then create the three objects (m,v,c) and avoid any dependencies. If that portion of the GUI is unlikely to be reused, then don't bother adding another level to the MVC hierarchy.
Should I simply return a Collection of data from the domain model
Yes. That is good, since many people make the mistake of storing the data entirely in the tableModel, but it's best to store your data in a Collection in your custom model class, and have the tableModel reflect any changes to that collection.
