• Post Reply Bookmark Topic Watch Topic
  • New Topic

are these comments correct about EJB 3 too?

 
raminaa niilian
Ranch Hand
Posts: 551
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
HI
Thank you for reading my post
I am reading Pro hibernate 3 and i find these snippet very odd, are they correct ?

thanks
---
� CMP Entity Beans require a one-to-one mapping to database tables.
� They are (by reputation at least) slow.
� Someone has to determine which bean field maps to which table column.
� They require special method names. If these are not followed correctly, they will fail
silently.
� Entity Beans have to reside within a J2EE application server environment�they are a
heavyweight solution.
� They cannot readily be extracted as �general purpose� components for other applications.
� They can�t be serializable.
� They rarely exist as portable components to be dropped into a foreign application�you
generally have to roll your own EJB solution.
---
 
Jeanne Boyarsky
author & internet detective
Marshal
Posts: 35719
412
Eclipse IDE Java VI Editor
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
I haven't used EJB 3 yet (just read about it). So some of this is from reading rather than experience.

> CMP Entity Beans require a one-to-one mapping to database tables.
Vendors have supported mapping to multiple tables for some time even though it wasn't in the spec. In EJB 3, mapping to multiple tables is in the spec. (I'm not sure exactly when it was introduced.)

> They are (by reputation at least) slow.
Definitely by reputation. Somewhat in practice. If you are only getting one record at a time, it isn't that noticeably. If you are doing a query, EJB was less than optimal. Not sure about EJB 3.

> Someone has to determine which bean field maps to which table column.
Yes. But this is true with any O/R mapping framework. It doesn't happen by magic. The few frameworks that don't require you to specify the mapping, rely on naming conventions where you must name the EJB fields and db columns in certain ways.

> They require special method names. If these are not followed correctly, they will fail silently.
True in EJB 2.1 and below. Although they rarely fail silently. More likely to fail with an obscure error message. EJB 3 requires special annotation names instead of special method names.

> Entity Beans have to reside within a J2EE application server
> environment�they are a heavyweight solution.
Yes. Of course that server is providing heavyweight services. If you need security and transaction support, the container is doing the work. If you don't need services, EJB is overkill for your requirements.

> They cannot readily be extracted as �general purpose� components for other applications.
Sure they can. We reuse EJB components plenty.

> They can�t be serializable.
EnterpriseBean is Serializable by definition. Maybe they mean that the references can't be serializable?

> They rarely exist as portable components to be dropped into a foreign
> application�you generally have to roll your own EJB solution.
I agree that they rarely exist as portable components. But they were designed to be. Maybe there isn't a market.
 
Mark Spritzler
ranger
Sheriff
Posts: 17290
9
IntelliJ IDE Mac Spring
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Those comments in the book are about EJB 2.x and are not valid in EJB3. Hibernate 3.x is an implementation of EJB3 JPA Spec plus Hibernate's added features.

Entity Beans in 2.x were not serializable, but in EJB 3. they are now POJOs, Plain Old Java Objects which can implement Serializable.

Mark
 
  • Post Reply Bookmark Topic Watch Topic
  • New Topic
Boost this thread!