Java EE design advice for a re-designed DB app

Question

I'm currently tasked with rewriting a legacy DB app in Java. The original was written in Delphi. It worked great for a number of years, but the powers that be have recently decided to redesign and rewrite it in Java. Basically I just have the same set of business requirements as the original did.
Overall, the app is a desktop GUI application that helps track contents of a natural history museum collection. The collection contains a bunch of specimens (dead animals) collected all over the globe at various times over the last 200 years. Multiple users (1 - 10 uesrs) will have to have access to the data at the same time. I also have to provide a nice Swing GUI for it.
Here's my question: Is this the type of app that lends itself to a Java EE design? I'm imagining using a Java EE app server that connects to the DB. The app server would provide DB access, producing entity beans, as well as managing a number of session beans (EJBs) that implement the business logic (security, user management/session management). I would also have a Swing GUI that would connect to the beans remotely. This sounds like it would help me keep a good disconnect between the UI layer (Swing), the business logic (EJBs), and the data layer (entity beans accessed using the Java Persistance API). Does this sound reasonable? I'm a veteran Swing developer, but not a seasoned Java EE developer/designer.
Also, if I use this architecture, I can imagine one issue that I might run into (I'm sure there are many others). I can imagine that I would want to retrieve the entity beans (lets say mypackage.MyPersonBean) through some call to an EJB, and then use the bean in some rendered Swing component. What happens when the Swing component needs to access the results of MyPersonBean.getAddresses() if the addresses are lazy loaded?
As you can probably tell, I really have more than one design question here. Help/comments about any of this is greatly appreciated.

Answer 1

I was thinking the same thing, but don't have a
successful experience to validate my gut feelings.
Here's my only suggestion (which dubwai could
hopefully confirm or correct): write your entity
classes/data model classes with no knowledge of
lazy-loading etc. Then subclass them, overriding
just the getChildren() type of methods and build the
lazy-loading knowledge into the subclass.More or less, yes. Don't over-think it, though. If you define your basic data 'types' as interfaces, you don't need to get into complex type hierarchies or multiple versions of the types unless that becomes necessary and if it does, the changes should not affect the presentation layer.
Since you are on-board with this and I think you are completely following, there is a technique for the lazy loading that you can use here.
In the case where it's a one-to-one relationship, you can do the lazy-loading by creating a simple wrapper class for the child object. This class will have a reference to either null or a filled in Object. This is a little more OO because the Object is taking care of itself. Whether this abstraction is useful to you, you will have to decide.
In the case of a one-to-many relationship, you can create a custom Collection (List or Set) that manages the stub loading. If you make a generic abstract version and subclass it for the different child types, you might be able to reuse a lot of the data retrieval code. You can do the same thing with the wrapper too.
I will caution you to try to keep it as simple as you can without painting yourself into a corner. Only do things that you are going to use now and write things so they can be expanded upon later. Reducing coupling is a core technique for that.
When the
GUI asks for an object in the getData() call, hand
them a subclass object, but don't let them know it.
In other words, have the method "public DataClass
getData()" return a SubDataClass object. The caller
will only know that they received a DataClass
object, but lazy-loading awareness will be built
into it. This way, the lazy-loading stuff is
completely transparent to the caller but you still
have simple data classes that can be used outside of
a lazy-loading context.Yes this is the idea, but don't write the other versions until you need them.
It's also possible to use
this method if you need to add transparent
lazy-loading to classes that you aren't the author
of. (Only classes that have been tagged 'final' or
have 'final' public methods would be beyond this
method's reach.)Yes, you can use the wrapper approach above but if the author of that class made a lot of unecessary assumptions you might have trouble.
This approach allows for some enhancements, too.You
can create a thread that retrieves the children of
Foo (e.g. bars) incrementally after the Foo is
returned to the caller. Often you can load the
bars
in the time it takes the user to click around to
the
point where they are needed or at least be partly
done. This will make the app seem very fast to the
user because they get the Foo very quickly (because
you didn't load the chidren) and then the bars
really
quickly (because you loaded them during user
'think-time').
I love this idea. I'm hoping to code this into my
GUI app soon.I would advise that you get the main lazy-loading working without this (keep in mind when writing the code) and do it once you are sure you will finish on time.