Re: Fad of the month Java data access question.

"Telemachus" <telemachus_at_ulysseswillreturn.net> wrote in message news:<6Jhia.6257$pK2.6361_at_news.indigo.ie>...
> Hi Nuno, thanks for that ( I did say people with strong opinions !)

Heh! That wouldn't be me.... ;)

>
> Otherwise I'm just going to go with whatever the chief developer wants (
> EJBs is his 'happy place' ) and the furore that this provoked on this NG a
> month ago is leading me to call for opinions.

There is a very definite trend away from EJBs as a "do-all" solution. They are very useful if you have an OLTP type application. In other words: small number of tables, high transaction rates, small transactions, need for scalability.

Anything other than these conditions and you buy a lot more trouble with EJBs than you gain. They can scale easily with additional nodes. But you pay a serious price for that: there is a lot of initial overhead in setting up EJBs for a large number of tables. Particularly with entity beans.

Just drop into a J2EE forum and ask them how do they manage to handle a 500 table database with the blighted things! Assuming you can find a forum where they know how to handle an application of that size. Most are still providing "examples" with three or four tables...

It would send most app servers' J2EE containers berserk. To put it mildly. Particularly if they are container managed. Yet 500 tables is not unreasonable for a medium functionality modern application.

JDO and/or DAO implemented as normal Java Beans for my money are still the best overall solution. They are fast enough to handle most if not all OLTP situations, can support complex designs with hundreds of tables and are relatively simple to implement. They work quite well in the MVC environment of J2EE and can support just about any other architecture you care to mention.

JDBC is not really a solution. Any connection to the database HAS to use JDBC anyway, whatever the overall architecture is. EJBs use JDBC to access the data. So, that's more of an enabling technology. Not really a defining one.

Of course, someone might consider using direct embedded SQL in Java code with JDBC access to the database. That is not really a very good solution, in the J2EE environment. Creates too many problems in defining what is a transaction, how it starts and ends, etcetc. But if all you have is applets in a web environment, nothing wrong with it.

All this to reinforce the idea: horses for courses. Look at your environment, how it's gonna grow, what apps you gonna be running, how they interact. Then pick the adequate Java data access technology. There is no magic silver bullet solution that can handle all situations. There never was.

Does this sound like the horrible "It depends"? You bet! :D

Cheers
Nuno Souto
wizofoz2k_at_yahoo.com.au.nospam Received on Tue Apr 01 2003 - 17:41:13 CST