We recently implemented a project using WL5.1 and TopLink for WL 2.5.1 (EJB 1.1). We started out implementing EJBs only for tables that corresponded to independent business objects, and regular Java objects for all other tables.
In many cases, our dependent objects in turn had their own dependent objects. This created a bit of a nightmare when I wanted to find a single fine-grained object, referenced via n-nested levels from a coarse-grained entity.
Also, in some cases, a dependent object may be dependent on two coarse-grained entities, or a coarse grained entity and a fine-grained object. In this case, we had to decide based on current need, which entity the dependent object was *more* dependent on.
Here is a small extraction from our data model:
Application - entity
Requirement - entity
Code - entity
ApplicationRequirement - dependent on Application and Requirement (1-n in both cases, an application has many app requirements, a requirement is present in many app requirements)
Order - dependent on ApplicationRequirement (many to many)
Result - dependent on Order (each result belongs to a single order, an order can have multiple results)
Detail - dependent on Result and Code. Each Detail references a Code. Each Detail belongs to a Result. A Result can have many Details.
Now, in my business operation, encapsulated in a session bean, I want to manipulate a specific group of Details that belongs to an Application, for example, all Details that have a specific Code.
I can do this by getting all Detail's corresponding to a specific Code. This would yield Details from many applications. It does not make sense to do this, since I am only interested in a single application.
So, I could also get an Application, obtain its ApplicationRequirements, its Orders, its Results look through all the Details in each case. This is a hell of a lot of processing for what I can obtain in a pretty simple SQL query.
Instead, we decided that if we were interested in a specific instance of an object, even if it was inherently dependent on another object, we would model it as an independent business object, ie: an entity bean, since we were essentially performing an independent business operation on this object, despite the fact that it was dependent.
By making the object an entity, it was quite simple to write a finder to do what we wanted, return a Detail based on its Application and Code references.
This ended up being the best solution, because fortunately we did not have too many entity beans in our model. If we did, this kind of approach might be detrimental.
I would like to discuss alternative approaches to this one, and/or the merits and drawbacks of the above approach.
Specifically I would like to address the following:
- When a fine grained object is dependent on two or more coarse grained objects, what is the best practice to use?
- Does EJB 2.0 spec improve this with EJBQL?
- Using BMP, fine-grained object access is simplified. But assume that we are using CMP to speed up development time. Tools such as TOPLink greatly helped in this respect, and we would like to continue using them.
I am very curious as to feedback on these issues.