DB abstraction summary? Making sense of the offerings...
John Wells
Greenhorn
Joined: Apr 10, 2003
Posts: 7
posted
0
Guys, There's an overwhelming amount of database abstraction/access libraries/frameworks/etc. available for Java. I'm returning to heavy Java db programming after years of absence (aside from some small code every now and then...), and don't really know where to begin. We used to write straight JDBC queries, but it seems the world has moved on, and I'd like to take advantage of the mass of innovation that has been done. Is there a central resource out there that summarizes the available options (JDO, DAO, Hibernate, etc. etc.) and offers the benefits/drawbacks as well as when you might want to use each? I appreciate any pointers or links or advice you can provide. Thanks for your help!
Hanna Habashy
Ranch Hand
Joined: Aug 20, 2003
Posts: 532
posted
0
hi John: I don't have much experience useing framworks for JDBC. I am still taking my baby steps. I found this book is very helpfull for me, and I thought you might want to take a look at it. Core J2EEpatterns, ISBN 0-13-142246-4
SCJD 1.4<br />SCJP 1.4<br />-----------------------------------<br />"With regard to excellence, it is not enough to know, but we must try to have and use it.<br />" Aristotle
Marshall B Thompson
Ranch Hand
Joined: Apr 11, 2002
Posts: 42
posted
0
My take is use jdbc to call stored procedures in your database. O/R layers get in the way in my opinion. Abstract something that a developer should already know (PL/SQL, T-SQL,...etc) into something new that they should learn. Makes debugging harder too. Go for simple and proven.
I've never been a fan of storred procedures since they either push logic to the database or split it between the database and the application (or application server). We have a new Object Relational Mapping forum for all questions of this type. You would get a better response there. Dave
Marshall B Thompson
Ranch Hand
Joined: Apr 11, 2002
Posts: 42
posted
0
I'm not advocating business logic in the stored procedures, but you should use them for CRUD operations. This is an ongoing debate. However; I contend that keeping sql out of the database and striving for database independence is not good. Tom Kyte makes the points brilliantly in his book, "Expert One on One Oracle". I won't repeat them here. See the first chapter (where he advocates using the database) for free in pdf form at: http://www.orafaq.com/books/samples.htm. Note that this first chapter will be good reading for Sybase, SQL Server,...etc developers. He compares the databases to make his points.
I agree. Here's the link: http://ej-technologies/jprofiler - if it wasn't for jprofiler, we would need to
run our stuff on 16 servers instead of 3.
subject: DB abstraction summary? Making sense of the offerings...
0
