Re: spring hibernate injection
On 03/02/2011 08:52 PM, Arne Vajh??j wrote:
On 02-03-2011 18:46, Lew wrote:
comp.lang.java.programmer wrote:
That's good and I have no wish to have a proxified class.
But how can I have a POJO DAO like in Apress "beginning hibernate"
that doesn't need to worry about sessions ie just
Session session = this.sessionFactory.getCurrentSession();
Don't use 'Session'. Use 'EntityManager'. The 'Session' interface is out
of date, supplanted by JPA.
Not really.
Hibernate today has two interfaces - the traditional and JPA.
You can not say that JPA is replacing the traditional - it is
supplementing it.
It is a good argument for using JPA that JPA is a standard and not
tied to Hibernate, but not everyone prioritize that aspect.
That is a good argument. There are others, and also times when JPA doesn't apply.
The main reason I prefer the JPA interface isn't that it's standard, it's that
it's easier.
I've used Hibernate itself both ways. While superficially cognate, and rumor
has it that Hibernate's implementation of one uses the other (too lazy to
check, myself), 'EntityManager' works better for me than 'Session'.
Maybe it's just the switch from XML to annotations that's the real reason.
I'm actually not sure why one works better. The idioms for
'EntityManagerFactory' (EMF) and 'EntityManager' (EM), whether manual or
injected, just plug in well with application logic, deployment descriptors and
JNDI to RDBMS configuration. Perhaps it is the standardness that makes it fit
so well in the overall deploy-and-run world, after all.
Object lifetime and size of the managed-data pool (per EM) are quite, er,
manageable with the JPA approach.
I'm not adept enough yet to speak to the managed-vs-unmanaged object
transitions that are useful but rather tricky. A lot of common situations are
covered by simple lightweight DA-layer service objects that carry their own
EMs with them.
It's a different way from monolithic DAOs that are tied to atomic data actions
on a single entity type. If you do that, you run into inefficiency and the
sorts of thing that I hear pejorative about Hibernate. Don't blame a hammer
if you have trouble cutting wood with it.
Instead, create services. Let the services figure out the persistence issues
for you. They can provide services for a particular entity, though often with
only a subset of its possible relationships. They can choreograph multiple
entities, e.g., as an order service for an online operation might.
Though hidden from service consumers, this approach lets you tie the life (and
crowdedness) of an EM to the need for its management capabilities rather
neatly. Monolithic approaches tend to create longer-lived EMs with lots and
lots more to manage and no easy way to reason about their state of management.
That's fine if you want to spend a lot of effort fighting your own
architecture. But good news: The diamond operator is coming!
--
Lew
Honi soit qui mal y pense.