• Post Reply
  • Bookmark Topic Watch Topic
  • New Topic

Aggregate/Composite Entity or Session Facade (Part II)

 
Roger Zacharias
Ranch Hand
Posts: 49
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Hi SCEAs and SCEAs-to-be!
I use EJB2.0 in my assignment so I have the possibility for the Aggregate/Composite Entity.
My question is:
When should I use the Aggregate/Composite Entity and when the Session Facade? They are very similar I think.
Are there any guidelines concerning this problem?
Regards,
Roger
 
Ajith Kallambella
Sheriff
Posts: 5782
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
I don't think they are similar. Let's see...
Session Facade is an implementation of the Facade pattern. It exposes coarse grained business methods and hides from the client the intricacies of (typically) several underlying components that actually fulfill the requirement. It is usually implemented using a session bean.
Coarse grained entity bean is an extention of a normal entity bean. Instead of being mapped to one underlying database table, coare grained/aggregate entity bean is mapped to multiple tables using sophisticated joins. The idea is to model business entities closer to client view instead of the physical data model.
Clearly they are two different things. Whereas session facade addresses client abstraction aggregate entity bean helps reduce isomorphism ie., bottom-up modelling.
Do you agree?
 
Roger Zacharias
Ranch Hand
Posts: 49
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Hi Ajith,
yes I agree, but I am uncertain about the business methods in the aggregate entity. Prior to EJB2.0 all operations like finding entities, adding sub-entities or deleting them, etc. were performed in the SessionFacade. Now a lot of this logic goes to the aggregate entity.
Can we say that only the �real business logic� like realization of workflows or contacting other systems stays in the session facade? Or how would you chop up the business logic?
Thanx
Roger
 
Ajith Kallambella
Sheriff
Posts: 5782
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
It is not a good idea( at least IMO ) to implement complicated business logic in entity beans be it fine grained or coarse grained. The entity beans should perform what they are designed to do best- persistence. Restrict your entity bean methods to getters and setters, doing "implied" calculations based on attributes and finders.
You may want to then implement finegrained business logic in session beans that call entity beans. I have also seen people implement business logic in utility classes and calling them directly from entity beans. This works too, but it is certainly not my favorite. The bottom line is, entity beans are not your best option to place the business logic.
Implement the workflow using session facade. These facades are the only business layer visible to the client and therefore implement fewer coarse grained methods. The facades internally calls other session beans and may call entity beans.
Hope this helps. Again, there are several ways to implment layering and every approach can be debated. No one approach works for all scenarios - use the one that best fits your requirements.
 
Roger Zacharias
Ranch Hand
Posts: 49
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Thank you very much, Ajith.
You have affirmed what I guessed :-)
That forum is great! So I now that I am not the only one that works in the evening.
 
  • Post Reply
  • Bookmark Topic Watch Topic
  • New Topic