Spring/hibernate and JDBC

J

Jack

With spring and hibernate so popular now, is there anybody still only
use JDBC to write database application code? Thanks.
 
M

markspace

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.).
 
J

Jack

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.).

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

Thanks.
 
J

Jack

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

Aéris

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Le 09/07/2011 23:56, Jack a écrit :
With spring and hibernate so popular now, is there anybody still only
use JDBC to write database application code? Thanks.

Unfortunately, yes…

With all the associated problems : unable to add new feature without
rewrite a very large proportion (all ?) of the code, no type safe,
explosion of the number of SQL queries usually hardcoded, etc.

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

iQEcBAEBAgAGBQJOGYvvAAoJEK8zQvxDY4P9nHkH/3e6xujzVwXcXeEb6YZ4q8Rf
dJmskyd+ZBF20Lf+DcQ7MPn0sQOsTGY4gPLn6adTPYTqJeHP8Nn9qDxLRwDuzZ3g
4MF10cT2NTe2VZT7Sy0SPYViQNr+fiEJL5JAahPcYfY2RBK0bmfR6b7VcXPq6coa
sUdlqDdVr2ML1hdi6ji/OM/3PHXYoHXtSHU0Bbnq60YbvYEk8J+4rLxVEqCOzlmb
MRse1U4GiN6Ji6AsG+bVdDFmwPlJ6IytZJzeI5myFpApWhhrD3lOZteni7Ws1nsU
91jFVCRv/2/p1CG+SNjj2SnXrAlsFT2FCsB2dtY0T06tW8DkDdGHn5Kw0lmPVsg=
=uYF8
-----END PGP SIGNATURE-----
 
A

Arved Sandstrom

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
 
A

Aéris

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Le 10/07/2011 02:32, Jack a écrit :
Is using JDBC to access database more efficient than using
Spring/hibernate?

Usually, Hibernate is the very most efficient.

Hibernate use 2 levels of cache to store query results and retrieved
objects.
For example, if you fetch one object, modify it 100×, and then delete
it, Hibernate does only 2 requests : select and delete. All update are
useless.
An other example is retrieving the same object 100× generate only one
select the first time, all others accesses using the Hibernate cache to
find the object.

But Hibernate could be very inefficient if your mapping is badly done.
Lazy loading could collapse your database engine under thousands of
short queries to fetch all children of one object.
On the opposite, eager loading could fetch the ¾ of your database only
with one query.

Hibernate is more efficient if you use it correctly.

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

iQEcBAEBAgAGBQJOGY4dAAoJEK8zQvxDY4P9dhUH/2FfGAO1NoM1HUEoK8518b8R
KOb4fXcEwE6L19SAOIrPWngbuhtdq1InO/we7sDogUfsqQJVyIGLT26hJ37e6Ppi
V27IYabTMMC+GMaPAx3mK7JnHr26T6+UvlaoENdJ5zzV/1yCZZLuBglSrOg24nsg
QiTd71rqMe7Vnjuaiurxr473vaVX3jASRoi0Y0lHvsBbX4cyognO3pxV/fzD0v+R
9+MbbqE0JnReU99BP9s0vlrpJy2tioQzT0KP0pPJHwHQU8eBkyOsT7A54jxrxJRf
L/5G6EoEQgLKLRVsT/mMKW8jowIyYDtX4wBxb/xGQtLxbDFGjhppCwYWAnby44Q=
=puE0
-----END PGP SIGNATURE-----
 
E

Elegie

On 10/07/2011 13:24, Aéris wrote :

Hi,
Unfortunately, yes…

With all the associated problems : unable to add new feature without
rewrite a very large proportion (all ?) of the code, no type safe,
explosion of the number of SQL queries usually hardcoded, etc.

You are right, but I believe you point at the wrong culprit. Is it the
fault of JDBC if a programmer does not decouple his design, does not
leverage design patterns, does not apply basic object-orientation
principles (open-closed principle, single responsibility principle come
to mind with the examples you have listed)?

It is not so difficult to design an application, separating cleanly the
different application layers, among which some data layer efficiently
encapsulating data access.

Frameworks are interesting because they somehow force good-enough
designs upon programmers. The final product shall be of higher quality,
but the programmer will not become any better (because he will
experience even less about application designing).

Regards,
Elegie.
 
A

Aéris

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Le 10/07/2011 13:56, Elegie a écrit :
You are right, but I believe you point at the wrong culprit. Is it the
fault of JDBC if a programmer does not decouple his design, does not
leverage design patterns, does not apply basic object-orientation
principles (open-closed principle, single responsibility principle come
to mind with the examples you have listed)?

Yes and no in same time.

I agree with you, it is possible to write good code using JDBC, but this
is a real pain because JDBC is not at all object-oriented, but
data-oriented. Obtained architecture is a real mess, using tricks and
bloated code one all levels.

So, good code is possible but efficiency « real usefull functionnalities
/ time passed » tends to 0 with JDBC « good architecture », and
discourages to do good things…

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

iQEcBAEBAgAGBQJOGZhnAAoJEK8zQvxDY4P9ou8H/i6umYntQ4WK9qghfFqnZrRE
kc8ajNUlEQwUUVJQ2oZdhOVhJJZ8w+hme70jxWfLCfnW7DQaPr/TpY/QI2VCdTCI
6CGffpsFdOdirnkKohx/uMimeUvhF5bCWyOtXajoGKIC6oSABh0rfCO8UMEz7mrx
ha75TN8c/OziBS2dOv2NH5PJRIoLYmLZRKGP8twpuEYnSs2HElTjtd4J5xidiqzw
2CYsL31YOA+aGo+ff8Acr4Zmc341c4ScQ1iteZyTUWoGwh9gCEdx+sO7qfj9DhwY
uV6+Ima6fihrHpG5DNeRaszlstDuNpL3Dy3JbhMbVwEtZfHJSzVBuwUzPNR+Ewg=
=GLbi
-----END PGP SIGNATURE-----
 
S

Stefan Ram

Jack said:
With spring and hibernate so popular now, is there anybody still only
use JDBC to write database application code? Thanks.

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?

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).

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!
 
T

Tom Anderson

I'm sure someone is, but yes I assume that JPA & Hibernate and
dependency injection frameworks like Spring and JSF have become the
norm.

This has also been my impression. On my current project, we do still write
raw SQL using JDBC on occasion, but only because we need to do some sort
of mad query that can't be done with our persistence provider. For
instance, we have a query that runs every hour to update our list of
top-selling products, which joins together all sorts of tables and inserts
the result directly into a table. I don't think there's any way to do that
(up to and including inserting from the select) with JPA.

Now, having said that, it appears that somebody doesn't see raw JDBC as
being limited to corner cases, because they've steadily been adding
features to it. Features i find quite baffling. Here's what's coming in
JDK 7 (skip over the try-with-resources stuff, which is great, but not
baffling):

http://download.java.net/jdk7/docs/technotes/guides/jdbc/jdbc_41.html

Who is the target market for this RowSetFactory stuff? In fact, who is the
target market for the existing RowSets? We have CachedRowSet,
FilteredRowSet, JoinRowSet, JdbcRowSet (!), and WebRowSet - none of which
i have ever seen used or advocated. Who is using these, and what for?

The javadoc for JdbcRowSet says:

A wrapper around a ResultSet object that makes it possible to use the
result set as a JavaBeansTM component. Thus, a JdbcRowSet object can be
one of the Beans that a tool makes available for composing an
application.

Waitwhat? Tools composing applications out of JavaBeans? Wasn't that idea
dead in, like, 1998? What the hell is going on here? Is there some mad
backwater Lost World of Java development where people are actually
building apps by dragging icons around in tools?

tom
 
A

Arved Sandstrom

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?

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).

FWIW, Stefan (and you likely know this), Oracle has EclipseLink as a JPA
implementation. And it's the reference implementation as well.

All that matters to me is that the Java Persistence API is in
javax.persistence, and it's considered to be a framework for _both_ J2SE
and J2EE/Java EE. That's standard enough for me. I in fact prefer that
the actual implementation decision is not made for me by bundling.
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!
What do you gain? The persistence API is standard after all. And are you
sure you'd want to have either Hibernate or OpenJPA or EclipseLink
(among others) hardwired into the J2SE distro? If Hibernate, for
example, were included, *I* wouldn't be all that happy, but many others
would be pleased. If EclipseLink were bundled, I'd be happy, but others
would be displeased. I see no win-win here.

It's exceptionally easy to include any of the common JPA implementations.

AHS
 
A

Arved Sandstrom

This has also been my impression. On my current project, we do still
write raw SQL using JDBC on occasion, but only because we need to do
some sort of mad query that can't be done with our persistence provider.
For instance, we have a query that runs every hour to update our list of
top-selling products, which joins together all sorts of tables and
inserts the result directly into a table. I don't think there's any way
to do that (up to and including inserting from the select) with JPA.

Short of using features that are peculiar to an implementation, it seems
to me that if you had that result table described as a JPA entity, you
could use an EJBQL constructor expression to load up the to-be-inserted
entities from that mess of joins. Persist _those_.

Just a thought. In real life I'd probably write the guts as a stored
proc, and have it run with a DB scheduler like Oracle Scheduler.
Now, having said that, it appears that somebody doesn't see raw JDBC as
being limited to corner cases, because they've steadily been adding
features to it. Features i find quite baffling. Here's what's coming in
JDK 7 (skip over the try-with-resources stuff, which is great, but not
baffling):

http://download.java.net/jdk7/docs/technotes/guides/jdbc/jdbc_41.html

Who is the target market for this RowSetFactory stuff? In fact, who is
the target market for the existing RowSets? We have CachedRowSet,
FilteredRowSet, JoinRowSet, JdbcRowSet (!), and WebRowSet - none of
which i have ever seen used or advocated. Who is using these, and what for?

The javadoc for JdbcRowSet says:

A wrapper around a ResultSet object that makes it possible to use the
result set as a JavaBeansTM component. Thus, a JdbcRowSet object can be
one of the Beans that a tool makes available for composing an
application.

Waitwhat? Tools composing applications out of JavaBeans? Wasn't that
idea dead in, like, 1998? What the hell is going on here? Is there some
mad backwater Lost World of Java development where people are actually
building apps by dragging icons around in tools?

tom
Seems like VisualStudio envy to me. And way behind the curve at that.

AHS
 
S

Stanimir Stamenkov

Sun, 10 Jul 2011 11:08:01 -0300, /Arved Sandstrom/:
Short of using features that are peculiar to an implementation, it seems
to me that if you had that result table described as a JPA entity, you
could use an EJBQL constructor expression to load up the to-be-inserted
entities from that mess of joins. Persist _those_.

I was just about to ask whether one have used such Constructor
Expressions in real life:

http://download.oracle.com/javaee/5/tutorial/doc/bnbuf.html#bnbwc
http://download.oracle.com/javaee/6/tutorial/doc/bnbuf.html#bnbwc
 
A

Arved Sandstrom

Sun, 10 Jul 2011 11:08:01 -0300, /Arved Sandstrom/:

I was just about to ask whether one have used such Constructor
Expressions in real life:

http://download.oracle.com/javaee/5/tutorial/doc/bnbuf.html#bnbwc
http://download.oracle.com/javaee/6/tutorial/doc/bnbuf.html#bnbwc
I have used them fairly frequently to prepare presentation models in
JSF, to use Martin Fowler's terminology. This is related also to view
models in Microsoft WPF.

To give an example, if a JSF dataTable has numerous columns, and quite a
few of them are fields of _many_ entities that are all retrieved by a
complex query with joins, it can be quite convenient to use a JPQL ctor
expression to load up a List of presentation model class instances. This
is more concise, and it more clearly keeps a division between
persistence and view backing data.

HTH,
AHS
 
T

Tom

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.).

Slightly off-topic I know but I gave up welding databases and class
designs together. Libraries with complex semantics and using xml to wire
up your application. Ugh.

Theory is here: http://www.inqwell.com/reify1.pdf

Regarding database access, practice is here:
http://www.inqwell.com/primer/keys.html#keytypes
 
J

Jukka Lahtinen

Jack said:
With spring and hibernate so popular now, is there anybody still only
use JDBC to write database application code? Thanks.

Yes.
I'm maintaining a large application that has all the database access
done with jdbc, mainly for historical reasons.

The application has been in production since the beginning of 2004, and
at some early point of the implementation project (about 2001 or 2002)
people experienced some problems with entity beans not always being
saved to the database in the correct order (or something like that, it
was before I got involved) and decided to switch to raw jdbc.

That was the days of Java 1.3 and ejb 2.1. If the application were to be
rewritten today, we would probably use hibernate or something.
 
G

Gunter Herrmann

Hi!
Still good to know what JDBC is and does, since it's used by JPA and
Hibernate (et al.).

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.

This approach additionally prevents any SQL injection.

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

Gunter in Orlando, Florida
 
L

lewbloch

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?

Use JPA when you want to code to an object model that persists itself,
without regard for the data-centric point of view. Use JDBC when you
need a relational model of your persistent data.

Eschew Spring.
 
L

lewbloch

  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?

  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).

  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!

JPA is a standard, and all implementations work with Java SE.

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? If it's needed, the app will include the JAR, since
every Java developer will use the JDK and therefore will have Derby.
That suffices.

One advantage of the current distribution strategy is that the
developer can choose the DB and JPA providers. Another is that the
user only gets the libs needed for their apps.

That the SE comes from wherever (Oracle, IBM, another party), the
database from wherever (Derby, Postgres), and the JPA from a third
(Oracle, Apache), is not a detriment but an asset. It's called
choice. Learn to like it.
 

Ask a Question

Want to reply to this thread or ask your own question?

You'll need to choose a username for the site, which only take a couple of moments. After that, you can post your question and our members will help you out.

Ask a Question

Members online

Forum statistics

Threads
473,744
Messages
2,569,484
Members
44,904
Latest member
HealthyVisionsCBDPrice

Latest Threads

Top