J
Jack
With spring and hibernate so popular now, is there anybody still only
use JDBC to write database application code? Thanks.
use JDBC to write database application code? Thanks.
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.).
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.).
With spring and hibernate so popular now, is there anybody still only
use JDBC to write database application code? Thanks.
Is using JDBC to access database more efficient than using
Spring/hibernate?
Is using JDBC to access database more efficient than using
Spring/hibernate?
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)?
Jack said: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.
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).
What do you gain? The persistence API is standard after all. And are youI 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!
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.
Seems like VisualStudio envy to me. And way behind the curve at that.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
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 have used them fairly frequently to prepare presentation models inSun, 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'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.).
Jack said:With spring and hibernate so popular now, is there anybody still only
use JDBC to write database application code? Thanks.
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?
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!
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.