Re: Design issue in swing application

Fencer wrote:


Lew gave some good links and advice. Here's the same stuff in a
slightly different format.

Normally, the Controller has references to the View and the Model, not
the other way around.

public class Controller {

   View view;
   Model model;

   public Controller ( View view, Model model ) {
     this.view = view;
     this.model = model;
     ...
   }
....
}

View would be some interface that this controller knows how to deal
with. Your View would be named "WelcomeScreen" or something like that;
this controller might be called a "WelcomeController". The
implementation of the view would be a JPanel or JFrame but your
controller wouldn't care about that.

The thing that receives the user interaction is the controller too. The
view only knows about the controller via a call back, so that needs to
be set.

   public Controller ( View view, Model model ) {
     this.view = view;
     this.model = model;

     this.view.addLoadFileActionListener( new ActionListener() {
       @Override
       public actionPerformed( final ActionEvent e ) {
         loadFile( e );
       }
     }
     ...
   }

   loadFile( ActionEvent e ) {
    ... show JFileDialog here...
   }

Something like that. (Note this controller now likely needs to be
synchronized and created on the EDT.)

The result is that your Controller is very procedural. It's a "driver
object". It mostly contains methods that drive the operation of your
program, it doesn't contain a lot of "state." This makes testing
easier. Try to keep controllers specific to one task or idea. If
needed, you should only have one action listener per controller. (More
are OK, if the concept is tightly scoped.) You may need lots of
controllers to implement a single window if that window has lots of
buttons or controls.

Views should be "dumb" and just fire events. Don't keep any state in a
view, other than the state it already has (like the text string in a
JTextField).

Model objects span the gamut. Some are "dumb," just data, like value
objects. Some are more active, and will do things like persists (save)
data, write to databases, or download from URLs or whatnot. It's up to
your design and your requirements how you do the model. Your model
would probably be a "BioModel".

In classic MVC, the model updates the view via a call back, and the view
has a reference to the model. However, Java uses a "split model" design
where views (JComponents) have their own model. So I think it's kind of
a toss up how your model updates the view when needed. I'd be inclined
to have it go through the Controller too, meaning no direct linkage.

In Java it's also possible to dispense with the Controller entirely and
just use the ActionLisenter. However, it's still a useful concept
sometimes, and you should at least keep it in mind for when it's useful.

That's my two minute lesson on MVC. Hopefully some of it is is even
correct. ;)


That's normal in software development. ;)