Entity Bean

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