I recently wrote a swing app w/hibernate. Your method works of course, but my approach was to seperate bus logic and db access from swing related classes. This will not be "easier" but will make it a lot easier to unit test, or change to SWT 3 years from now. ;-)
Unfortuneately there is not a lot of good swing programming examples out there, and there does not seem to be re-usable frameworks like a struts for swing.
In our "framework" we have a service layer that handles all hibernate access. Basically singleton classes, or classes w/ static methods.
We created something called the "applicationstate" which is similar to an http session(a hashmap wrapper class), and a listener infrastructure, such that one a model (hibernate) object changes, screens can be nofified that there were changes in the objects.
We used the Command pattern to handle all actions. This is kind of built in to swing in 1.4, but for reasons I don't remember, it didn't work for us...
Advantage of doing this work is screens don't know about each other, screens are very "dumb", and we can unit test the service layer.
Also multiple open windows can make changes to objects, without screens having to tell each other things.
Disadvantage: more work up front building the framework, more classes...
--James
|