Hurrah for EJB 3.0. I haven't really dwelled into EJB 3.0 yet. But these having been made closer to being POJOs as possible makes it more enticing. It is what I am often calling as back-to-roots. Really, the extra complexity of EJB development made it less favored compared to .Net, LAMP, or even java-based IoC containers. Now, EJB 3.0 is as POJO as it can get, I'd never blink and think twice in upgrading our EJBs to this spec. However, Entity beans are still far from being included in any solution that I propose. And why not? It is because concretized and tested DAO-based solution works for us. Why infuse Entity beans? If it ain't broke, why fix? I think wanton usage of Entity beans just because they're entity beans is an anti-pattern. I'd
rather go into JDO if that's the case.
I'll be embarking on a mission to overhaul some of our components. Session beans and MDBs will be one aspect of the proposed solution. We'll see...
What's new in EJB
Friday, August 19, 2005
EJB 3.0 promise
Subscribe to:
Post Comments (Atom)
1 comment:
Could you please elaborate a bit about what you don't like about EJB3 entity beans? EJB3 entity beans are essentially hibernate3 pojos. You can hide them behind a DAO if you want, and EJB3 session beans make great pojo DAOs because of entity manager injection and free TX management.
I think the DAO model is an anti-pattern from the J2EE days. I'd prefer to work with the entity manager directly where possible. (keep in mind that EJB3 persistence doesn't require a full EE container, so you aren't tying the application down or limiting testing or anything) The entity manager is really a generic DAO object that keeps you from having to create little DAO objects. Where you do want a separate DAO type object, EJB3 persistence still makes sense. From the user perspective you just see the EJB3 entity POJO. From the implementation perspective, you get the entity manager and the full power of EJB3.
Post a Comment