MVC data exchange patterns

Question

Hi,
I've been reading about the Model - View - Controller pattern in Java, but can't seem to find the thing I need. My application has a GUI that contains several JComponents in the form of classes,most of which extend JPanel. As far as I understand the MVC in Java, graphical components have underlying models that hold the data that the component visualizes. When extending JPanel, I have created a 'model' object for each of my different panels. Those classes are simple information-holders with mostly get/set methods and little else. One JPanel paints some Java2D graphics that I want to be able to export as image when the user chooses that option from a menu. The menu is contained in the main GUI class, and so is the component with the drawing. I am looking for a good way to do this, some sort of standard pattern. My own ideas so far are these:
1. Pass a reference of the GUI to the menu, so the menu can access the component where the image is and get it itself. (really ugly way but will probably work).
2.The menu notifies its listener- the GUI -that the user pressed something. The GUI calls the get-methods, collects whatever is needed, and does whatever is needed(saves the file in a certain format in my case). (keeps the menu a purely view-element, but makes the main GUI class deal with the reset of the work.
3.Have some sort of controller that fetches the data and saves the file. With this one the problem is where is the controller? Does the menu have a reference to it, or only the main GUI? So far I don't have a specific controller-class, because the whole design looks like a bunch of smaller MVC's into a bigger one(all the models for the components are properties of a bigger model class that is responsible for creating them), and I just didn't know where to place that controller.
I'd very much like to hear your thoughts about those three options, and suggestions for how to do it the 'right way'.

Answer 1

bee2525 wrote:
Hi,
I've been reading about the Model - View - Controller pattern in Java, but can't seem to find the thing I need. My application has a GUI that contains several JComponents in the form of classes,most of which extend JPanel. As far as I understand the MVC in Java, graphical components have underlying models that hold the data that the component visualizes. When extending JPanel, I have created a 'model' object for each of my different panels. Those classes are simple information-holders with mostly get/set methods and little else. One JPanel paints some Java2D graphics that I want to be able to export as image when the user chooses that option from a menu. The menu is contained in the main GUI class, and so is the component with the drawing. I am looking for a good way to do this, some sort of standard pattern. My own ideas so far are these:
1. Pass a reference of the GUI to the menu, so the menu can access the component where the image is and get it itself. (really ugly way but will probably work).
2.The menu notifies its listener- the GUI -that the user pressed something. The GUI calls the get-methods, collects whatever is needed, and does whatever is needed(saves the file in a certain format in my case). (keeps the menu a purely view-element, but makes the main GUI class deal with the reset of the work.
3.Have some sort of controller that fetches the data and saves the file. With this one the problem is where is the controller? Does the menu have a reference to it, or only the main GUI? So far I don't have a specific controller-class, because the whole design looks like a bunch of smaller MVC's into a bigger one(all the models for the components are properties of a bigger model class that is responsible for creating them), and I just didn't know where to place that controller.
I'd very much like to hear your thoughts about those three options, and suggestions for how to do it the 'right way'.<caveat-emptor disclaimer="I'm *NOT* an OOP design guru. Several of my collegues leave-me-for-dead when it comes to designing/architecting for intangible, cross-cutting, non-functional concerns." />
They're all "not _too_ bad" as far as I'm concerned.
Option 1 is inflexible, but it does have the advantage of simplicity.
Option 2 is almost infinitely more flexible than 1... except I cringle (a bit) at the phrase "the GUI ... does whatever is needed"... Dude, GUI's don't do stuff... they just display stuff, that's why they're called "user interfaces"... so there's got to be a better way.
Option 3 trys to address the code-smell inherent in option 2... but all it's really done is moved the logic from one place it doesn't belong to some other place it doesn't belong.
Option 4 ... Hmmmm... So let's see here... The business at hand is retrieving, displaying, ?editing?, and saving pictures, right? These "operations" might be grouped together under the banner: "picture management". Picture management would (IMHO) be best done by public class PictureManagerV1 implements PictureManager.
What I'm trying to say is that MVC is NOT the whole picture... often there are other "layers" involved.... especially a business layer.
The general steps are:
1. the controler creates the business layer
2. the controler asks the business layer to "initialise" the model.
3. the controler creates the view, passing it a reference to the business layer.
4. the view interpolates user-requests into business requests, and presents the replies.
So what we've done is basically to "split the controler" into two.
Part A: is specific to this app... it knows "a bit" about everything... the business layer, the specific view, and (almost inevitably) this specific model.
Part B: is the "business layer" which ecapsulates the business operations. It does NOT know about this specific view (though it knows that there is a view)... and therefore theoretically may be reused "out of the box" to provide "business level services" in any application.
To achieve this "reusability" the "rule" is that you only cross the line between controler and business via an interface (at minimum).
The controler basically just "sets everything up" and then stands back and watches it play until the end of the game, when it's responsible for cleaning up...
The view asks the business layer to perform a service. When the view needs to be updated as a result of changes to the model then it's the business layers responsibility to "call back" the view... which it could do via a passed-in "event" interface... or it you could go-the-whole-hog and use a "subscription" pattern.
+-----------+
| Controler | creates     +----------------+ uses       +--------------+
| + main    |------------>| Business       |----------->| DAO          |
+-----------+             | + transactions |            | + operations |
          |               +----------------+            +--------------+
          |                  ^          | notifies          | persists
          |                  | uses     |                   V
          | creates       +--------+    |         +-------------------+
          +-------------->| View   |<---+         | Model (DTOs)      |
                          | + show |              | + get/set         |
                          +--------+              +-------------------+Likewise the business layer could "inject" listeners into the model itself, but that presumes that model is "smart", and I personally prefer a "dumb" model... just a graph of simple data transfer objects (the bean, the whole bean, and nothing but the bean) with "the smarts" all ripped-out and stuffed in the "bottom" of the business layer... which naturally leads us to recognising yet another distinct layer, the Data Access layer, which exposes the "raw" CRUD operations: create, read, update, delete (and I personally add locate / find to that list) this alleviating the business layer from the concerns of dealing with the details inherent in what-ever data-storage mechanism (like flat-file vs LDAP vs distributed heirarchical-mash-relation database management system) we happen to be using... and again "the divorce is consumated" with the rule: allways cross this line via an interface.
Petty much all the above ideas are stolen from gurus, who gave them willingly... but the above is my take on what I've read and practiced over the past few years... it's most probably flawed, possibly seriously... but it seems to work OK for me thus far, but bewarned that I have not yet even attempted to apply these ideas on "full scale industrial size application".
Cheers. Keith.