I read with interest Ed Roman's great article from August last year on the wrap-entity-bean-with-session-bean pattern: https://www.theserverside.com/patterns/thread.jsp?thread_id=625
- Posted by: Matthew Kennedy
- Posted on: June 19 2001 00:52 EDT
I've been studying the Pet Shop example, which takes the apporach of a (BMP) entity bean delegating access to a database through so-called Data Access Objects (DAO). I see some parallels here, which cause me some confusion. It seems to come down to what you think an entity bean is for.
With the Session-Bean-Wrap-Entity-Bean pattern:
- The session bean provides the business logic
- The entity bean provides the data model
With the DAO pattern:
- The entity bean provides the business logic
- The DAO provides the model
Either way, it seems to me that both satifsy the analogy of noun-verb (the paper-writer analog one user in the thread replied).
The only drawback I can see for the DAO pattern is that the enitity bean involved is no longer suitable for CMP. Or am I wrong.... What do y'all think?
- Session Bean wrap Entity beans, or Entity Bean wrap DAO? by Pratap Das on June 20 2001 02:06 EDT
The basis of using DAOs is two-fold. One, entity beans as is available (implemented?) today are fine for transactional updates but perform very poorly when getting lists of entities. Secondly, CMP technology is still immature in that it cannot be used in most enterprise situations (eg: table joins, etc). Also, CMP also has the same problems entity beans implementations have in regards to unnecessary ejbLoads & ejbStores. The DAO concept is apparently a stopgap measure which compensates for the drawbacks that CMP & entity beans have.
By migrating all your data access logic away from the entity bean into the DAO sets stage for a later migration of data access code into CMP mode (whenever CMP is ready for prime time). Also, the DAO can be used independently by other beans to retrieve lists of rows instead of using unweildy finder methods.
I do not think that the intention is to move business logic into the entity bean. The business logic remains on the session bean and the entity bean simply delegates the actual boilerplate SQL codes into the DAO. The DAO would have additional methods (as required) to allow the retrieval of list of objects, which may in turn be returned via ValueObjects.
Would be interested in knowing what others think.