Spring/hibernate and JDBC

[Aéris]

-----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
SQoXxQGgCG2mxKQfB3zx7jjLZCIG1AShMP2wkN6qROwfvPHTDsHwRsoJMyPca346
3IFNQZQ8H/YCsjTupfmrUxhsrJipwr04usgYkvAu4BMqZbGXTVSrpa4oiUkMNw32
8RbRgPxjW7+V5Ibrjfy1n8sSptwEa2DM893vbxMBbhejudDLLlGCg7CimsYDhFkU
JDznZxtCpit3Mnu27HQVE4J89/gLTPkSaFXDqIOMlNM/mnbmppHSo+Ydwt/8Kx4=
=owYR
-----END PGP SIGNATURE-----

 

[Stefan Ram]

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/theplanetarium/entry/project_jigsaw_modularizing_jdk_7

 

[lewbloch]

  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.

 

[Jack]

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?

 

[lewbloch]

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.

 

[Gene Wirchenko]

On Mon, 11 Jul 2011 17:06:37 -0700 (PDT), lewbloch

[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

 

[Arved Sandstrom]

On Jul 11, 11:25 am, lewbloch <[email protected]> wrote:

[ SNIP ]

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

 

[iadb]

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

 

[Arne Vajhøj]

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

 

[Arne Vajhøj]

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

 

[Arne Vajhøj]

What are the pros and cons of using Spring/hibernate and JDBC?

ORM (incl. Hibernate) provides you with an OO view that fit well
with an OO language like Java and you save a ton of trivial
code.

JDBC supports types of database access that are not object oriented
and are in general easier to follow regarding what is going on.

If the database access is object oriented then I will recommend
using ORM and if necessary get the developers properly trained.

Arne

 

[Arne Vajhøj]

I have yet to encounter intelligent
use of Spring in a real project.

Eschew Spring.

Spring can be very nice if you only use the original Spring stuff (*).

The problem is if you try to use all the Spring stuff, because a
gazillion relative unrelated stuff got bundled into Spring.

Arne

*) Maybe CDI will remove the need for even the original Spring stuff,
but CDI is still pretty new.

 

[Arne Vajhøj]

Certainly using spring/hibernate has a shorter development circle than
JDBC and the code is easier to maintain.

Only if the developer knows Hibernate.

(Spring is many things so unless you qualify what part of Spring you are
talking about then it is pointless to discuss)

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?

Hibernate should perform as well as JDBC, but see above.

Arne

 

[Arne Vajhøj]

I like the idea of JPA, but AFAIK, no implementation is part
of Java SE? So the canonical way to develope a desktop
application with JPA would be to mix Java SE with a database
and a JPA implementation?

Yes.

It works fine.

Working in SE context was one of the design goals behind
entity beans -> JPA as far as I remember.

I dislike to depend on too many different libraries and
providers (i.e., Java SE is provided by Oracle, Hibernate by
another party, the database possibly by another party).

Today it is common to need 20-30 different open source libs.

Just a mental barrier to get over.

I am disappointed that Derby is only part of the JDK, but
not of the JRE. I surely would love Derby and an JPA
implementation to be part of Java SE!

Could make sense.

Arne

 

[Arne Vajhøj]

If you want to create complex database centered applications and
want decent security you would create an API in the database
without any direct access to tables for the application.

Very often you have different applications running the same
type of tasks even based on different programming languages.

Just imagine a hotel reservation system (single property).
You have the following apps creating/updating reservations:

1. The local property management system
2. The chain's central reservation system
3-10. 3rd party reservation systems (for travel agent reservations)
11. Hotel's web site
12. Chain's web site
13-20. Other web sites doing reservations for you.

If you use a capable DB (such as Oracle) you do everything via
packaged stored procedures and (pipelined or not) table functions.
You cannot trust any outside application, so do the same for
your own stuff.

If you want to expose the same let us call it low level business
logic to multiple apps in different technologies, then moving
that logic to an SP layer in the DB tier is one way of doing it.

The con is that a divorce from your database vendor becomes
extremely costly.

A modern alternative solution to the same problem is to have the
different apps use the same (web) services.

This approach additionally prevents any SQL injection.

No it does not.

SQL injection can potentially also happen with SP's.

In reality it never happens, because when people know how
to use SP's they also know how to avoid SQL injection.

But then they would also know how to avoid it in Hibernate,
plain JDBC etc..

In this case Hibernate is pretty useless (just an additional layer
of framework heavily using reflections making debugging more
complicated than necessary.

It avoids the database dependency.

It gives a good OO view of data.

It is trivial to get it to output the actual SQL it executes.

Definitely not useless in general.

Arne

 

[Tom Anderson]

Spring can be very nice if you only use the original Spring stuff (*).

The problem is if you try to use all the Spring stuff, because a
gazillion relative unrelated stuff got bundled into Spring.

*) Maybe CDI will remove the need for even the original Spring stuff,
but CDI is still pretty new.

True. EJB3 also took a big step into Spring's space. It is different to
Spring in some large ways and some small ways, but it's pretty widely
supported, and is something to consider.

If CDI had been invented several years ago, the world would be a better
place. I recently got involved with a question about using CDI to
configure a JBoss JMX service:

http://stackoverflow.com/q/6723260/116639

And it struck me that the wheel of configuring object instances from has
not only been reinvented a tragic number of times, but it's even been
reinvented several times within a single project or platform, like JBoss
or J2EE. Something like CDI (maybe something a bit bigger - i think you
need a uniform way to use files to drive configuration, alongside
autowiring), done well, could have preempted all those inventions, and
saved a huge amount of time and wailing and gnashing of teeth.

tom