Velocity Reviews - Computer Hardware Reviews

Velocity Reviews > Newsgroups > Programming > Java > Spring/hibernate and JDBC

Reply
Thread Tools

Spring/hibernate and JDBC

 
 
Aéris
Guest
Posts: n/a
 
      07-11-2011
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Le 11/07/2011 20:25, lewbloch a écrit :
> I have yet to encounter intelligent
> use of Spring in a real project.


Spring is only usefull for IoC to do a n-tier application (domain, dao,
service).
Spring is totally bloated and useless when you use it for its Hibernate
tools (Hibernate template and others).

- --
Aeris
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.11 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/

iQEcBAEBAgAGBQJOG0RrAAoJEK8zQvxDY4P9+mcH/3doZ2PuHCWEJx3rWHptLlNt
xkuHpEMFaYfWaT3DsjdNDlgpxodatvLs1/zDp1BOpDpawFkRVWmTbcQePojCCDx5
SQoXxQGgCG2mxKQfB3zx7jjLZCIG1AShMP2wkN6qROwfvPHTDs HwRsoJMyPca346
3IFNQZQ8H/YCsjTupfmrUxhsrJipwr04usgYkvAu4BMqZbGXTVSrpa4oiUkM Nw32
8RbRgPxjW7+V5Ibrjfy1n8sSptwEa2DM893vbxMBbhejudDLLl GCg7CimsYDhFkU
JDznZxtCpit3Mnu27HQVE4J89/gLTPkSaFXDqIOMlNM/mnbmppHSo+Ydwt/8Kx4=
=owYR
-----END PGP SIGNATURE-----
 
Reply With Quote
 
 
 
 
Stefan Ram
Guest
Posts: n/a
 
      07-11-2011
lewbloch <(E-Mail Removed)> writes:
>Derby is free to distribute and not always needed in every JRE
>installation, so why include it for the grand majority of users who
>don't need it?


Java SE 6u10 is only loading a 4.5 MB kernel of the 15 MB Java SE,
and more changes in this direction are intended. So I was hoping
that it might be possible today or in the near future to download
Derby on demand. But even if this would not be possible: A decent
means to store data in a database is essential for so many applications
that it even would be worth an increase in the size of Java SE.

1
http://blogs.oracle.com/theplanetari...larizing_jdk_7

 
Reply With Quote
 
 
 
 
lewbloch
Guest
Posts: n/a
 
      07-11-2011
Stefan Ram wrote:
> lewbloch writes:
>> Derby is free to distribute and not always needed in every JRE
>> installation, so why include it for the grand majority of users who
>> don't need it?

>


> * Java SE 6u10 is only loading a 4.5 MB kernel of the 15 MB Java SE,
> * and more changes in this direction are intended. So I was hoping
> * that it might be possible today or in the near future to download
> * Derby on demand. But even if this would not be possible: A decent
> * means to store data in a database is essential for so many applications
> * that it even would be worth an increase in the size of Java SE.
>
> * 1http://blogs.oracle.com/theplanetarium/entry/project_jigsaw_modulariz...


"A decent means to store data in a database" != "Derby".

Your statements don't speak to my point. It may be that Derby is a
member of the set of "decent means to store data", but it's not the
only member. Leaving the question of why to include Derby for every
user whether they need it or not.

To include Derby for every user, when some apps use SQL Lite, some use
Derby, some use something else entirely, is not optimal. Presumably
that's the reason why, like so much else in the JDK, it's not in the
JRE. You don't get other parts of the JDK either.

--
Lew
 
Reply With Quote
 
Jack
Guest
Posts: n/a
 
      07-11-2011
On Jul 11, 11:25*am, lewbloch <(E-Mail Removed)> wrote:
> On Jul 9, 5:32*pm, Jack <(E-Mail Removed)> 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?

>
> Yes and no. *It can be more efficient as a programmer to use Hibernate
> (but don't use Spring!), at least if you stay with the JPA-compliant
> parts of Hibernate. *It can run more efficiently to use JDBC without
> JPA, but usually is not.
>
> Unfortunately, most use of Hibernate in the wild is quite ignorant and
> harms the respective projects. *I have yet to encounter intelligent
> use of Spring in a real project.
>
> Good use of JPA will make your program quite clean and maintainable,
> i.e., very efficient in the development and maintenance dimensions.
> Bad use of JPA, like bad use of a chain saw, results in a horror-movie
> scenario. *For certain bulk operations, JDBC is better.
>
> 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.
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?
 
Reply With Quote
 
lewbloch
Guest
Posts: n/a
 
      07-12-2011
On Jul 11, 4:39*pm, Jack <(E-Mail Removed)> wrote:
> Certainly using spring [sic]/hibernate [sic] has a shorter development circle than
> JDBC and the code is easier to maintain.


Not in my experience. Badly written Spring code, which is all I've
ever seen, is terribly difficult, lengthy and expensive to maintain.
Badly written Hibernate code, which I have seen, likewise. The
majority of Hibernate code I've seen (across several projects that
used it) was all badly written. The problem came about with Hibernate
because people used it in lieu of SQL (i.e., raw JDBC calls) rather
than to support an object model.

> 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?


That depends, and has been answered upthread. Properly used, JPA-
based code (including Hibernate) can be faster than raw JDBC,
depending on the use patterns. Only you can answer this question. We
cannot, based on the paucity of information you provide about your
scenario(s). Your question is like asking, "Which relieves pain
better, aspirin or acetaminophen/codeine?" The answer depends on the
problem you're trying to solve.

The question you should be asking is which one suits your logic
better. Do you need to maintain an object model that must persist?
Chances are that Hibernate is useful and will help you - IF YOU KNOW
WHAT YOU'RE DOING! If you don't, neither Hibernate nor JDBC can save
you.

The key is that JPA (don't use "native" Hibernate!) supports an object-
oriented model; JDBC supports a set-oriented model. When set
operations are needed, JPA gets in the way. When object-oriented
operations are needed, JDBC gets in the way. Use what's right for the
problem. You will never (NEVER!) get a reliable answer to "which has
better performance?" unless you write your code correctly (!),
appropriately to the programming model and MEASURE the performance.

Development and maintenance costs are more important than tiny
differences in runtime cost. You might find that there is no
measurable difference at runtime. Code correctly first, and only
address performance in the face of a demonstrated bottleneck.

Stop repeating your question until you've assimilated the good answers
you've already received, please.

--
Lew
 
Reply With Quote
 
Gene Wirchenko
Guest
Posts: n/a
 
      07-12-2011
On Mon, 11 Jul 2011 17:06:37 -0700 (PDT), lewbloch
<(E-Mail Removed)> wrote:

[snip]

>Stop repeating your question until you've assimilated the good answers
>you've already received, please.


And this may help you pose more useful questions:
http://www.catb.org/~esr/faqs/smart-questions.html
How To Ask Questions The Smart Way
by Eric Steven Raymond

Sincerely,

Gene Wirchenko
 
Reply With Quote
 
Arved Sandstrom
Guest
Posts: n/a
 
      07-12-2011
On 11-07-11 08:39 PM, Jack wrote:
> On Jul 11, 11:25 am, lewbloch <(E-Mail Removed)> 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
 
Reply With Quote
 
iadb
Guest
Posts: n/a
 
      07-17-2011
On Jul 9, 5:56*pm, Jack <(E-Mail Removed)> wrote:
> With spring and hibernate so popular now, is there anybody still only
> use JDBC to write database application code? Thanks.


Spring jdbc module is similar to jdbc where we can write the code same
as jdbc..


http://www.internetarticlesdb.com

 
Reply With Quote
 
Arne Vajhj
Guest
Posts: n/a
 
      07-21-2011
On 7/9/2011 5:56 PM, Jack wrote:
> With spring and hibernate so popular now, is there anybody still only
> use JDBC to write database application code? Thanks.


Yes.

Either due to the code being very old or due to special
requirements.

Arne

 
Reply With Quote
 
Arne Vajhj
Guest
Posts: n/a
 
      07-21-2011
On 7/9/2011 8: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?


As Hibernate is using JDBC then in theory JDBC will always
be at least as fast as Hibernate.

In practice I would say that Hibernate is often as fast
as manually written JDBC code but occasionally much slower.

When it is much slower it is typical because:
- the developer did not understand hibernate sufficiently
well (it is very typical for ORM to be very easy to get
the code working but it requires deep understanding to
actually get it working right - because the ORM hides
what is going on behind the scenes)
- the task was not suited for ORM

Arne
 
Reply With Quote
 
 
 
Reply

Thread Tools

Posting Rules
You may not post new threads
You may not post replies
You may not post attachments
You may not edit your posts

BB code is On
Smilies are On
[IMG] code is On
HTML code is Off
Trackbacks are On
Pingbacks are On
Refbacks are Off


Similar Threads
Thread Thread Starter Forum Replies Last Post
Re: [JDBC] JDBC Driver and timezones Lew Java 0 05-19-2010 03:33 PM
How to parse the jdbc driver name from the jdbc .jar file Bruce Java 4 03-25-2006 12:01 PM
stand-alone JMS, other JDBC operations, and transactions ( ActiveMQ + JOTM + JDBC operations ) Jesus M. Salvo Jr. Java 2 02-11-2006 06:33 PM
oracle.jdbc.OracleDriver vs oracle.jdbc.driver.OracleDriver Betty Java 1 05-21-2005 05:15 PM
Re: jdbc help:sun.jdbc.odbc.JdbcOdbcDriver Keith Wansbrough Java 0 08-16-2004 07:31 PM



Advertisments