Last week, we had the author of TDD for a Shopping Website LiveProject. Friday at 11am Ranch time, Steven Solomon will be hosting a live TDD session just for us. See for the agenda and registration link
I'm wondering if anybody working on the assignement is using the composite entity pattern using CMR to manage dependent business objects. To me, it seems a little complicated when we start to include business object dependencies. Is there any other way? For example how about implementing your dependent object as POJOs. What will be pros and cons of both these approaches ?
It is important to note that this pattern is still viable with EJB 2.0 and Local Entity Beans. In both a local and a distributed environment there are drawbacks to using remote entity beans to model fine-grained or dependent business objects, so the composite entity pattern is applicable in both cases. Before EJB 2.0 existed, a common strategy for composite entity implementations was to use a Remote Entity Bean for the parent and use Java objects instead of remote entity beans for the dependent objects in a parent-child relationship. This also meant that the parent usually used Bean-managed persistence so it had to write the code to manage the relationships to the other objects also. But with the introduction of local entity beans in EJB 2.0, the strategy of using local entity beans to model fine-grained entities and dependent objects is recommended. An additional benefit of this strategy is that since all the objects in this strategy are Entity beans, you can efficiently use container-managed persistence and avoid writing code to manage the relationships.
If you go thru Core J2EE Patterns 2nd Edition, Business objects can be implemented as POJO objects. As long as you plan to have a Facade (SLB) in front of the main business object you do not need to have an Entity bean.
Once upon a time there were three bears. And they were visted by a golden haired tiny ad:
Free, earth friendly heat - from the CodeRanch trailboss