EntityBean: One form taken by
EnterpriseJavaBeans. Represents actual data in a database.
Or, to put it another way, they represent business objects that happen to require persistent data. As opposed to
SessionBeans, which provide services (business logic) without representing a persistent entity. A 1:1 correspondence with tables in an RDBMS is neither required nor very desirable.
I think the EJB spec writers had something more elaborate in mind. Yes, many EJB servers and CMP implementations assume 1 bean == 1 RDBMS table, but I think the designers had something more like domain objects in mind. It's just that persistence, life cycle and domain object state have been jammed into a single idiom.
-
ChrisRaber
On good days, I think the writers were simply inexperienced in dealing with OO-RDBMS issues. I can imagine them finishing
SessionBean part and thinking 'RDBMSes are used much in the real world, so we need something to work with them in our spec'.
On bad days, I think some joker just slipped them into the specification and they became one of the largest practical jokes in the history.
The mapping of the domain objects (or some say it the wrapping of the domain objects with entity beans) to entity bean is typical. Not all domain objects can be represented using the
EntityBeans. Like for example if I have a Address table and a Customer table at first I would map both of them to
EntityBeans. But as we know, the
EntityBeans are bulk components and we don't want to make them fine grained. It would be a better idea to make Address just a normal
java object (probably a
JavaBean) and Customer an
EntityBean. The main idea here is wrap the independent domain objects into
EntityBeans and the dependent objects as normal
JavaBeans. As you said, the other things that we should consider when selecting the appropriate
EntityBeans is the life time.
-
SeshKumar
Something that's bothering me about entity beans are all the different criteria by which I may need to locate collections of entity beans. Do I write a custom finder for each (perhaps parameterized) set of criteria? This can get quickly out of control. I've seen persistence layers that allowed you to create a collection of objects from a SQL statement, but that kind of punches through the whole "abstraction" thing, doesn't it?
-Paul Busch
CategoryEjb