Path: csiph.com!x330-a1.tempe.blueboxinc.net!usenet.pasdenom.info!goblin1!goblin2!goblin.stu.neva.ru!feeder1.cambriumusenet.nl!feeder3.cambriumusenet.nl!feed.tweaknews.nl!193.201.147.78.MISMATCH!feeder.news-service.com!postnews.google.com!news2.google.com!npeer03.iad.highwinds-media.com!news.highwinds-media.com!feed-me.highwinds-media.com!post01.iad.highwinds-media.com!newsfe04.iad.POSTED!8ad76e89!not-for-mail From: Arved Sandstrom User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.9.2.17) Gecko/20110424 Lightning/1.0b2 Thunderbird/3.1.10 MIME-Version: 1.0 Newsgroups: comp.lang.java.programmer Subject: Re: Spring/hibernate and JDBC References: <3c16e5e7-3c0b-4126-9dd9-88f372a58f03@e26g2000prf.googlegroups.com> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Lines: 71 Message-ID: X-Complaints-To: abuse@newsgroups-download.com NNTP-Posting-Date: Sun, 10 Jul 2011 11:27:50 UTC Organization: Public Usenet Newsgroup Access Date: Sun, 10 Jul 2011 08:27:48 -0300 Xref: x330-a1.tempe.blueboxinc.net comp.lang.java.programmer:6036 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