Object hierarchies in memory and pattern usage strategies.
[this should maybe be a story, and is under construction. I plan to add som models etc. comment if you like! but its more to come... ]
I've been working since mid-jan now with a reengineering of a SQL Server solution. Our task is to port the part of their system containing Contact information to J2EE.
We have structured all information in a sensible UML Domain diagram showing all conceptual classes. Starting the real implementation design we need to make a couple of architectural decisions. The communication between layers need to be done according to the ValueObject pattern. The best strategy for this would probably be a combination between "Updateable VO" and "Multiple VO" as described in Sun's paper.
(For pure .NET folks out there VO's can be compared with strongly typed datasets.)
Because this is a application mainly aimed at webclients we need to make some decisions regarding state preservation in the application layer. This is really also a OR-mapping issue..
J2EE with architectural ornaments - MS Access Style with bloatcode
The obvious simplest solution would be to route requests from the clients directly through stateless session beans (service beans) to the DAO's to get the appropriate VO's. Implementing the "Multiple VO" strategy the client (or the service the client uses to access the app SOA style) will be able to retreive either a "heavy" VO containing aggregated information, or "lightweight" VO's containing only key/value pairs for it's collections.
The lightweight solution would then demand another call on the application to obtain the VO's for the aggregated objects (which really are just structs because they are VO's). These objects can easily be stored in client session.
This whole solution with passing VO's up and down through the layers creates a lot of chatter and traffic. To me this does not feel really OO. It feels like databound MS Access forms with architectural patterns strapped to it to make it run on JBoss. The architecture becomes mere ornaments and you could just as well have executed sql in the presentation layer.
Maintaining complete object hierarchy in-memory
The alternative would be to load all objects into memory at startup or first use. This way, using stateful session beans, each client could make requests on references to real objects directly, with these references placed in their state on the application layer.
The big "how" in this scenario is search. How to do an effective complex search in large object hierarchies? If I have 4000 contacts of different types with sub-contacts and aggregated objects etc. it would probably take ages to do what a simple SQL SELECT could do in seconds. But the select won't work if I have to have _just that_ object.. Not a copy..
You could, of course, maintain partial object hierarchies in stateful beans only. But in this case two sessions would work on separate copies of an object creating a possible lost update.
to be continued..
would all of this go away with JDO (or objectSpaces for .NET)?