Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]
Groups > comp.lang.java.programmer > #6036
| From | Arved Sandstrom <asandstrom3minus1@eastlink.ca> |
|---|---|
| Newsgroups | comp.lang.java.programmer |
| Subject | Re: Spring/hibernate and JDBC |
| References | <3c16e5e7-3c0b-4126-9dd9-88f372a58f03@e26g2000prf.googlegroups.com> <ivamk9$dph$1@dont-email.me> <a8ce2398-e1f7-4dfd-966e-48e8daa03416@p10g2000prf.googlegroups.com> |
| Message-ID | <W0gSp.58282$F25.57695@newsfe04.iad> (permalink) |
| Organization | Public Usenet Newsgroup Access |
| Date | 2011-07-10 08:27 -0300 |
On 11-07-09 09:32 PM, Jack wrote: > On Jul 9, 4:01 pm, markspace <-@.> wrote: >> On 7/9/2011 2:56 PM, Jack wrote: >> >>> With spring and hibernate so popular now, is there anybody still only >>> use JDBC to write database application code? Thanks. >> >> I'm sure someone is, but yes I assume that JPA & Hibernate and >> dependency injection frameworks like Spring and JSF have become the norm. >> >> Still good to know what JDBC is and does, since it's used by JPA and >> Hibernate (et al.). > > Is using JDBC to access database more efficient than using > Spring/hibernate? Define "efficiency". Is it runtime efficiency - knowing that you've got the best possible SQL statement for actual load conditions - or is it development efficiency - producing adequate DB access code in an acceptable amount of team time? There are a number of considerations that come into play. A major one is the fact that only a minority of developers have sufficient SQL-fu and also specific RDBMS knowledge to do a better job of writing SQL than a JPA persistence provider like Hibernate or EclipseLink will. That's to say, one does not usually observe that standalone native SQL written by a given programmer is substantially better than the SQL generated from EJBQL which is written by the _same_ programmer. In fact, in a dev shop where coders are allowed too free rein to write native SQL in a JPA context, their SQL is often worse than if they had expressed their solution within the constraints of EJBQL. Unless they are top-notch people. With the latest JPA (version 2.x) there is also a type-safe criteria API that offers more benefits than what the accessors available on JDBC's ResultSet and PreparedStatement do. You can certainly do some typesafe queries with JDBC's DataSet but at this point you're simply edging into functionality that JPA takes for granted as basic. In deciding what approach to take, I myself would not worry about runtime performance excessively, at the gitgo, other than making sure that regardless of whether the DB access code is in SQL or EJBQL, that the coders are competent with the underlying fundamentals of accessing an RDBMS. A coder who is not competent here will write an abortion either way. To put it another way, the programmer should be capable of producing good SQL, no matter what, but given that they may in fact _then_ be better off writing EJBQL in a JPA environment. Assuming basic competency, you'll really only discover at testing time what DB accesses are not up to snuff in terms of performance. This would be true for either straight JDBC (possibly using something like MyBatis, though) or JPA with Hibernate or EclipseLink. At this stage of the game your programmers may well engage the help of a DBA for some fine-tuning. Much of the fine-tuning will have little to do with the actual SQL anyway. Myself I tend to go with JPA 2, and only those DB accesses that either cannot be fully expressed in EJBQL, and/or are complex enough that they are better off in a stored procedure, usually end up in hardcoded SQL someplace. Bear in mind that modern JPA persistence providers offer a lot of customization features for finetuning, so it's rare to encounter a _performance_ situation that forces you to use native SQL. One larger consideration is persistence management. It is _both_ a pro and a con of JPA that you place your persistent data, in the form of objects, under the management of the persistence provider. This is such a large topic that it's probably best the subject of another thread. But it's absolutely an important factor in deciding between JPA and straight JDBC. AHS
Back to comp.lang.java.programmer | Previous | Next — Previous in thread | Next in thread | Find similar
Spring/hibernate and JDBC Jack <junw2000@gmail.com> - 2011-07-09 14:56 -0700
Re: Spring/hibernate and JDBC markspace <-@.> - 2011-07-09 16:01 -0700
Re: Spring/hibernate and JDBC Jack <junw2000@gmail.com> - 2011-07-09 17:29 -0700
Re: Spring/hibernate and JDBC Arne Vajhøj <arne@vajhoej.dk> - 2011-07-21 17:55 -0400
Re: Spring/hibernate and JDBC Jack <junw2000@gmail.com> - 2011-07-09 17:32 -0700
Re: Spring/hibernate and JDBC Arved Sandstrom <asandstrom3minus1@eastlink.ca> - 2011-07-10 08:27 -0300
Re: Spring/hibernate and JDBC Aéris <aeris@imirhil.fr> - 2011-07-10 13:33 +0200
Re: Spring/hibernate and JDBC lewbloch <lewbloch@gmail.com> - 2011-07-11 11:25 -0700
Re: Spring/hibernate and JDBC Aéris <aeris@imirhil.fr> - 2011-07-11 20:44 +0200
Re: Spring/hibernate and JDBC Jack <junw2000@gmail.com> - 2011-07-11 16:39 -0700
Re: Spring/hibernate and JDBC lewbloch <lewbloch@gmail.com> - 2011-07-11 17:06 -0700
Re: Spring/hibernate and JDBC Gene Wirchenko <genew@ocis.net> - 2011-07-11 21:37 -0700
Re: Spring/hibernate and JDBC Arved Sandstrom <asandstrom3minus1@eastlink.ca> - 2011-07-12 07:01 -0300
Re: Spring/hibernate and JDBC Arne Vajhøj <arne@vajhoej.dk> - 2011-07-21 18:00 -0400
Re: Spring/hibernate and JDBC Arne Vajhøj <arne@vajhoej.dk> - 2011-07-21 17:58 -0400
Re: Spring/hibernate and JDBC Tom Anderson <twic@urchin.earth.li> - 2011-07-22 17:24 +0100
Re: Spring/hibernate and JDBC Arne Vajhøj <arne@vajhoej.dk> - 2011-07-21 17:52 -0400
Re: Spring/hibernate and JDBC Tom Anderson <twic@urchin.earth.li> - 2011-07-10 13:34 +0100
Re: Spring/hibernate and JDBC Arved Sandstrom <asandstrom3minus1@eastlink.ca> - 2011-07-10 11:08 -0300
Re: Spring/hibernate and JDBC Stanimir Stamenkov <s7an10@netscape.net> - 2011-07-10 17:45 +0300
Re: Spring/hibernate and JDBC Arved Sandstrom <asandstrom3minus1@eastlink.ca> - 2011-07-10 17:35 -0300
Re: Spring/hibernate and JDBC Steve Sobol <sjsobol@JustThe.net> - 2011-07-10 09:42 -0700
Re: Spring/hibernate and JDBC Tom <tom400f@gmail.com> - 2011-07-10 22:29 +0000
Re: Spring/hibernate and JDBC Gunter Herrmann <notformail0106@earthlink.net> - 2011-07-11 10:19 -0400
Re: Spring/hibernate and JDBC Arne Vajhøj <arne@vajhoej.dk> - 2011-07-21 18:09 -0400
Re: Spring/hibernate and JDBC Aéris <aeris@imirhil.fr> - 2011-07-10 13:24 +0200
Re: Spring/hibernate and JDBC Elegie <elegie@anonymous.invalid> - 2011-07-10 13:56 +0200
Re: Spring/hibernate and JDBC Aéris <aeris@imirhil.fr> - 2011-07-10 14:17 +0200
Re: Spring/hibernate and JDBC Arved Sandstrom <asandstrom3minus1@eastlink.ca> - 2011-07-10 10:44 -0300
Re: Spring/hibernate and JDBC Jukka Lahtinen <jtfjdehf@hotmail.com.invalid> - 2011-07-11 09:52 +0300
Re: Spring/hibernate and JDBC lewbloch <lewbloch@gmail.com> - 2011-07-11 11:31 -0700
Re: Derby and Java SE (was: Spring/hibernate and JDBC) lewbloch <lewbloch@gmail.com> - 2011-07-11 15:46 -0700
Re: Spring/hibernate and JDBC iadb <freeinternetarticles@gmail.com> - 2011-07-17 10:17 -0700
Re: Spring/hibernate and JDBC Arne Vajhøj <arne@vajhoej.dk> - 2011-07-21 17:47 -0400
Re: Spring/hibernate and JDBC Arne Vajhøj <arne@vajhoej.dk> - 2011-07-21 18:02 -0400
csiph-web