Re: JDBC, PreparedStatement and named parameters
Daniel Pitts wrote:
Depending on your needs, a JPA provider (such as Hibernate) may be a
A word to the wise: if you do use Hibernate itself, as opposed to, say,
Apache OpenJPA or EclipseLink, make sure you use it as a JPA framework,
and not as old-style Hibernate.
better approach. It moves you away from low-level SQL, and into more
object oriented notation.
For certain values of "better".
It is often better to use raw JDBC.
You can more or less fake out named parameters with a combination of
java.sql.PreparedStatement and an enum for the indexes.
JPA has its own query language that directly supports named parameters.
It isn't always the best solution, and my experience with Hibernate has
been mixed. It's worth looking into and learning about it. They tend
Hibernate is fine if you restrict yourself to the newer JPA approach.
EclipseLink and OpenJPA know no other way.
Keep your EntityManagers short-lived and don't share them across threads.
Keep your EntityManagerFactory long-lived, and IIRC it's shareable.
You have to use JPA in an idiomatically Java way to get its full value.
to be useful if you do exactly what they were designed for, and then
they get in your way when you need to do something different.
The use case for raw JDBC is bulk operations.
For object-to-relational mapping the JPA ORM frameworks are great.
Don't get too fancy with your JPA.
--
Lew