Composite Entity Bean v. Session Facade
1 posts in topic
Flat View  Flat View
TOPIC ACTIONS:
 

Posted By:   rock_roll
Posted On:   Monday, June 3, 2002 08:21 PM

I've read mixed reviews in the past regarding the use of the composite entity bean pattern. I definitley can see how the pattern makes sense. However, what if you are using a session facade to manage all entities and there is no inter entity bean interaction, is this still bad form? For example, lets say I have a entity Sales Person, and an entity Product Bonuses. Should product bonuses be a collection within sales person, or is it okay to have it as an entity of its own accessed via it's own session facade and value object factory? The one-to-one relationship mapping between database and objests I agree is not ideal, but want to get some real world feedback. Any help would be appreciated. Ro   More>>

I've read mixed reviews in the past regarding the use of the composite entity bean pattern. I definitley can see how the pattern makes sense. However, what if you are using a session facade to manage all entities and there is no inter entity bean interaction, is this still bad form?


For example, lets say I have a entity Sales Person, and an entity Product Bonuses. Should product bonuses be a collection within sales person, or is it okay to have it as an entity of its own accessed via it's own session facade and value object factory?


The one-to-one relationship mapping between database and objests I agree is not ideal, but want to get some real world feedback.


Any help would be appreciated.
Rock.

   <<Less

Re: Composite Entity Bean v. Session Facade

Posted By:   Vincy_Kalvar  
Posted On:   Thursday, August 29, 2002 09:03 AM

Hi,
I think this may interest u.......
I found this reply for a posting similar to ur's...


For example, Order and Order Lines, there should be a composition relationship b/w Order Value Object and OrderLine Value Object.


OR


Order Entity Bean can have a method "Collection getOrderLines()". In this way there is no relationship in Value Object and our VO are fine grained objects not course grained



There are, in fact, even more options in designing this than those outlined in your post.



For example, you can employ an entity bean facade pattern in which a stateless session bean is aware of the relationship. You would create a method named getOrderLines(String orderId) which would return a collection of value objects. Employing this pattern is good because it abstracts all the knowledge of how multiple entity beans relate to each other. Spreading this knowledge accross the application is not desirable.



You can also implement the order/order line relationship as a single BMP. The clients would view these 2 tables as one. Outside of using raw JDBC, this would give you the best performance since your SQL joins would be done by the database as opposed to the application. This could be used with the facade as descibed in the previous paragraph(I.E have a stateless sessionbean and call the method on BMP called getOrderAndLines().



As far as coarsed-grained vs fine-grained, there are no hard and fast rules. Having a coarsed-grained VO is good if you happen to need most of the data you are fetching but bad if you just need a single field. One thing is for sure though, keep your session bean methods coarsed-grained and pass around VO to your clients - not the entity beans themselves.



-VK

About | Sitemap | Contact