BC4J DAOs vs. Local Entity Beans

Question

We are beginning a brand new project and trying to evaluate the costs/benefits of using BC4J entity objects versus local entity beans for our persistence needs.
I've read the "Simplifying J2EE and EJB Development with BC4J" white paper including the "How Does EJB 2.0 Change the Picture?" section, but that seems to have been written at a time when EJB 2.0 support was a rarity.
I'd like to get some feedback from people who have had experience with both. We are basically starting this application from scratch, although we have relational tables from our legacy C++ application that will serve as the basis for the Java object model. So what would we gain/lose by using entity objects?
I must admit, I'm leaning toward using entity beans over a vendor-specific persistence framework, but if there are compelling reasons to choose entity objects (besides those mentioned in the white paper), I'd like to hear them. Please speak slowly, as I'm new to BC4J. :)
Thanks for your time.

Answer 1

I've read the "Simplifying J2EE and EJB Development with BC4J" white paper including the "How Does EJB 2.0 Change the Picture?" section, but that seems to have been written at a time when EJB 2.0 support was a rarity.IMO there's no change.
What Sun doesn't tell you in the specs, but is much talked about on theserverside.com and in most
anti-patterns threads, and in the up coming book J2EE Anti-Patterns; EJB Entities are basically
broke with no solution. Reason: EjbStore() can throw an exception due to DB constraint violation
after the business method returns. This drives the scenario where all business integrity is
forced up into the middle tiers (EJB and business mediator tiers). etc etc ... EJB Entities are
useful for the 5% to 1% of a business model and application that is transactional IMO.
I.E. 95%++ of most apps/web sites are read only. Why use a heavy and expensive transactional
component for reading rows from a DB to be displayed on an Inventory screen? The only reason
to do this is if you have stock in Sun and your appserver vendor or want your project to last
forever or get canceled. -- Seriously, do your home work, using Entities as your persistance
tier mediator, for the 95% of your project that's read only, and for reports which involve
joins, select criteria etc etc will be a serious problem to just code and even bigger problem
to be responsive and scalable.
Do this experiment: implement a report that joins several tables, selects on where criteria,
orders by some attribute in EJB Entity bean technology. Seriously try to code this solution.
Hint: spray water on your appserver box since it'll almost explode. :)
Then try: do the same report in SQL. One SQL statement usually will do it and it's all in the
DB. The data returned to the middle tier is ready for JSP formating.
Try another EJB experiment: implement a finder based on criteria that returns a Collection.
Do the same in SQL: time the perf difference.
Hint: Maybe you're getting the picture, that EJB Entity 2.0 --> 10.0 what-ever, never wrote into
the specs any means for joins, or high perf finders based on criteria.
My opinion and experience: EJB Entity is good for one portion of a project if that; the single
part that's transactional (usually the shopping cart or similar). All other data access needs
to be through a DAO tier that's SQL based. With BC4J you get transactional support too, so
why bother with EJB, except to be wrapped by SLSB's for remotability from the client.
I'd like to get some feedback from people who have had experience with both. We are basically starting this application from scratch, although we have relational tables from our legacy C++ application that will serve as the basis for the Java object model. So what would we gain/lose by using entity objects? I'm at the end of phase one of a medium scale BC4J project which was initiated after scrapping
a Sun Blueprint J2EE 1.2 architecture for the above reasons, plus the unmentioned time to market
issue. We found hand coding the Sun architecture to be 400% slower, if you don't hit any of the
above mentioned bumps in the road. We never got to reports, which would have been imposible without
custom DAOs.
I must admit, I'm leaning toward using entity beans over a vendor-specific persistence framework, but if there are compelling reasons to choose entity objects (besides those mentioned in the white paper), I'd like to hear them. Please speak slowly, as I'm new to BC4J. :)You're not the first to ask this question nor the last. Sun's happy talk in the face of their
king has great cloths sell job to fend off .net will take more than just J2EE Anti-patterns books
to displell. Try the reports and finders experiements in EJB 2.0. You'll no doubt learn alot
and read more news group posts in the process.
Heck, you might even discover that 903 oc4j's CMR and EQL can instantiate 1000's of Entity beans,
JNDI entries, return a Collection of handles, your client get the ValueObjects and build a report
in less than a minute and 100's of customers can do this simultanteously. __NOT__ :)
Cheers,
curt