Path: csiph.com!x330-a1.tempe.blueboxinc.net!newsfeed.hal-mli.net!feeder1.hal-mli.net!nx02.iad01.newshosting.com!newshosting.com!69.16.185.16.MISMATCH!npeer02.iad.highwinds-media.com!news.highwinds-media.com!feed-me.highwinds-media.com!post01.iad.highwinds-media.com!newsfe05.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: 54 Message-ID: X-Complaints-To: abuse@newsgroups-download.com NNTP-Posting-Date: Tue, 12 Jul 2011 10:01:47 UTC Organization: Public Usenet Newsgroup Access Date: Tue, 12 Jul 2011 07:01:46 -0300 Xref: x330-a1.tempe.blueboxinc.net comp.lang.java.programmer:6108 On 11-07-11 08:39 PM, Jack wrote: > On Jul 11, 11:25 am, lewbloch wrote: [ SNIP ] >> >> Asking about "efficiency" for use of JPA vs. JDBC calls is like asking >> if it's more efficient to use an automobile than a bicycle. The use >> cases differ, so where one is more appropriate the other is less so, >> and "efficiency" has little to nothing to do with it. That is to say, >> "efficiency with respect to what?" is your real question. >> >> So, efficiency with respect to what? > > Certainly using spring/hibernate has a shorter development circle than > JDBC and the code is easier to maintain. You can probably find a tutorial/example scenario, or a specific toy application, that fosters the impression that Spring+Hibernate has a shorter development cycle than JDBC, and is easier to maintain. In general it's my belief that the opposite is true, and that's with Hibernate (or EclipseLink) only, not even including Spring. The use of Spring substantially adds to the maintenance burden of an application; I'll leave off discussing it because I don't know why anyone wants to use it these days. A fair comparison of JDBC versus JPA has to assume that competent developers are applying best practices to both. In either case a data access layer (DAL) will contain the persistence code; the rest of the application simply sees domain objects and uses "repository" methods to do things with them. As much thought and effort goes into deciding what domain classes will be exposed to the rest of an app by a JPA-based DAL as for a JDBC-based DAL. Of course you might be thinking of not using a DAL at all, and using JPA directly in every layer. That's a prescription for maintenance problems straight off. I recommend against it...although I think I might be a voice in the wilderness on this point. JPA is _not_ easier to use than JDBC. It may often be less _laborious_ to use, but that's for one-time only coding anyway. But JPA as an API that has to be understood well is not easier than JDBC. This goes directly to the maintenance argument. > Here for efficiency, I mean performance. For a server with frequent > and large amount of database accesses(insert/delete/update), which way > has a better performance? Neither, or both. In all cases that type of performance depends on the instructions sent to the DB, and generally speaking both JDBC and JPA can issue the same instructions. That type of performance depends on the competence of your developers. AHS