I'm reading the Session Facade pattern of Mr. Floyd Marinescu's EJB Design Patterns Book. In page 10, it advices not to put domain logic in the Session Facade session bean, where it saids "domain model should contain all the business/use case logic in your applicaiont. Most Session Facade methods should simply delegate to the appropriate entity bean...". It sounds like the entity beans should contains all the domain/business logic while Session Facade beans should just coordinating the usage of different entity beans to realize the use case behavior.
- Posted by: arthur chan
- Posted on: May 27 2004 12:22 EDT
However, on the same page on a differnt bullet named "Good usuability", it says, "The encapsulation of application logic into session beans means that our entity beans can contain data and data access logic only, making them reusable across sessions beans in the same or even in different applications."
I'm a little confused about the seemingly contradict descriptions on the same subject. Maybe my understanding of domain model is different. But it seems to make more sense for the Session Facade beans to contain the business logic while the entity beans just to model the persistence business objects.
Please kindly provide some insight and/or clarification of this. Many thanks in advance.
- Where is the business logic by Mike B on May 27 2004 16:27 EDT
- Session Facade - Placing Domain Logic in session beans by Joe Attardi on May 28 2004 09:53 EDT
If I understand the question that you have - you are basically asking where does the business logic go. If that is not the question I apologize.
Scanning the example in the book it is using an Account/Transfer Fund example showing how a method on a Session Facade like transferFunds(userPK, accountPK, accountPK2, amount) is better than the 6 calls needed using Entity Beans to try to accomplish the same thing. In this exampe it would appear that the BL to withdraw and deposit are in the EB. For example withdraw(amount) may have a check to see if their is enough $ in the account. Therefore my guess is that is why the book states "Session Bean should delegate to appropriate Entity Bean"
However I think the main point being made is that the Facade layer is not a good place to put biz logic. The Session Facade's main purpose is to minimize the number of NW calls (among other things) by creating a coarse grained interface. (see p.5 of EJB Design Patterns Book). So the Session Bean is an access point for the client to get at biz logic.
However in general where the biz logic goes and how data is persisted is definately widely debated but in general:
SessionFacade method is used to make multiple calls out to other components/objects that contain the BL.
- these components/objects that are called by the Session Facade method could be:
1. Entity Beans (as in the example)
2. other Session Beans which rely on Enity Beans
3. other Session Beans which use DAO (or other framework like JDO etc.)
4. POJOs which use DAO (or other framework like JDO etc.)
Hope this clears it up (at least a little)
My preference is to minimize the code in the session bean itself. Usually, I will have some kind of an "Application Service" object (just a POJO) which contains the actual business logic. Then, all the session facade really does is instantiates one of these Application Services and run the business logic. Check out the Application Service design pattern at http://www.corej2eepatterns.com/Patterns2ndEd/ApplicationService.htm .
If you haven't read it, I highly recommend Core J2EE Patterns: Best Practices and Design Strategies by Alur, Crupi, and Malks. It's a wonderful collection of design patterns.