== how to handle Item/ItemList entities with EJB ? == There is a pair of objects in my sample application which are in relation as Item/ItemList. For example, imagine a browsing application for the product catalogue, where the list of named priced items should be displayed. The underlying database have the only table named 't_item'. What is the best/correct EJB design solution for O/R (Object-Relational) mapping of the database records into an Item/ItemList object pair ? I suppose there should be 2 EJBs: The first one (let's name it 'Item' - Entity Bean) implements the full set of ejb-required methods such as find_by_pk/create/update/remove + business method to return object's state (value object). The second ('ItemList' - Stateless Session Bean) implements the only selector business method returning a collection of entity id's using some criteria (page number and item count on a single page) and no modification methods. At the presentation tier (jsp) when I need to display the list the following happens: a list of id's is fetched by calling ItemList session bean; then for each (!!!) id the value object fetched by calling Item entity bean; results formatted and displayed on a page. THE QUESTIONS ARE: Is there a way (correct according to EJB concepts) to reduce an amount of remote calls ? I think Sun's PetStore sample do Item/ItemList browsing in the same a quite straightforward way, with no care of performance. Where can I find good samples of an application design close to real-world needs ?
thank your all, -- Mike P.S. It's just for educational purposes; pls don't advise me any O/R mapping tools, I want to implement the solution 'by hand'.
I believe that the formal name for this is "parent-child" - you are attempting to provide a composite view of a one-to-many relationship. <rant-mode> I hate the word "best". It's sloppy - usually "best" solutions are limited to situations that often rarely occur in the real world. It also is inexact - if we wanted the "best" response time, we'd be using custom hardware and networking software and for sure wouldn't be using Java. The only thing worse than saying "best" is putting the word "the" in front of it - you've limited yourself mentally by assuming there's only one true solution. </rant-mode> OK, now that I've let off steam The generally-accepted model is to let a session EJB provide the facade of the composite view and let it manage entity EJBs for both of the the components (parent and child). This is architecturally very clean - easy to understand and easy to modify. There are also claims it's fairly efficient, though I've not seen them enumerated - I would assume that they'd be related to intra-VM RMI, plus possibly (if you use a stateful EJB), holding the entity beans a little closer to the client. Of course, REAL efficiency freaks say you should forswear EJBs altogether and do direct JDBC from a servlet. I've learned not to get too worked-up over "efficiency", but to treat writing a program as though it were a logic problem or mathematical proof. A good solution is simple and clean. A frequent side-effect of that is efficiency. And when it's not efficient enough, it's easier to replace modules for tuning purposes than to attempt to unravel a big quirky ball-of-yarn solution and wind it into a new ball of yarn. Ball-of-yarn programs tend to be more prone to strange errors, and the one thing worse than an inefficient program is one that fails unpredictably. The OTHER reason why I don't make low-level efficiency a design goal is that on the systems I've been called on to optimize, measurement tools have always indicated that the REAL bottleneck was never where I "knew" it would be.
Customer surveys are for companies who didn't pay proper attention to begin with.