«

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

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

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

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

Thanks.

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?

-----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+DcQ7MPn0sQOsTGY4gPLn6adTPYTqJeHP8N n9qDxLRwDuzZ3g
4MF10cT2NTe2VZT7Sy0SPYViQNr+fiEJL5JAahPcYfY2RBK0bm fR6b7VcXPq6coa
sUdlqDdVr2ML1hdi6ji/OM/3PHXYoHXtSHU0Bbnq60YbvYEk8J+4rLxVEqCOzlmb
MRse1U4GiN6Ji6AsG+bVdDFmwPlJ6IytZJzeI5myFpApWhhrD3 lOZteni7Ws1nsU
91jFVCRv/2/p1CG+SNjj2SnXrAlsFT2FCsB2dtY0T06tW8DkDdGHn5Kw0lmPV sg=
=uYF8
-----END PGP SIGNATURE-----

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

-----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
QiTd71rqMe7Vnjuaiurxr473vaVX3jASRoi0Y0lHvsBbX4cyog nO3pxV/fzD0v+R
9+MbbqE0JnReU99BP9s0vlrpJy2tioQzT0KP0pPJHwHQU8eBky OsT7A54jxrxJRf
L/5G6EoEQgLKLRVsT/mMKW8jowIyYDtX4wBxb/xGQtLxbDFGjhppCwYWAnby44Q=
=puE0
-----END PGP SIGNATURE-----

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

Hi,

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

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.

-----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/OziBS2dOv2NH5PJRIoLYmLZRKGP8twpuEYnSs2HElTjtd4J5xi diqzw
2CYsL31YOA+aGo+ff8Acr4Zmc341c4ScQ1iteZyTUWoGwh9gCE dx+sO7qfj9DhwY
uV6+Ima6fihrHpG5DNeRaszlstDuNpL3Dy3JbhMbVwEtZfHJSz VBuwUzPNR+Ewg=
=GLbi
-----END PGP SIGNATURE-----

Jack <> writes:
>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!