- Introduction
- The Entity Bean Handle Dilemma
- The CMP Entity Bean Dilemma
- The Space vs. Time Dilemma
- The Deployment Descriptor Portability Dilemma
- The Object-Oriented vs. EJB Development Dilemma
- The Assurance Dilemma
- Overcoming the Dilemmas
- Conclusions
Like this article? We recommend
Like this article? We recommend
Like this article? We recommend
The Object-Oriented vs. EJB Development Dilemma
Given our discussion so far, you should consider two facts:
Entity bean implementations entice you to create beans that implement pure object-to-relational mappings without much business logic baked into the beans, especially CMP entity beans.
It is desirable to design session beans as the front-line interface by which clients communicate with an EJB application server and act as an intermediary between the clients and the entity beans.
I've found that these design considerations that account for certain EJB limitations and performance dilemmas can lead you to create servers in which most (if not all) of the business logic for an application is contained within session beans. Thus, the entity beans serve as pure object-to-relational maps for passive repositories of data. Therefore, rules applied to data before it is read, updated, or deleted by a client may be localized within a session bean. This localization of logic within a session bean that is separate from the data contained in an entity bean violates certain object-oriented (OO) best practices. Instead, in an OO development paradigm, you should explicitly co-locate the logic within the object or component that will operate on the data. Of course, this can be partially overcome by locating the logic that operates on entity data within the entity bean—again, this is not much of a problem for BMP entity-bean implementations. However, it is indeed a subtle design consideration when creating session and entity beans.