[Springframework-developer] Hibernate3 entity names, direct Session access

[Juergen H. <ju...@in...>]

We've just received a request for further overloaded methods on
HibernateTemplate: taking Hibernate3 entity names as alternative to Class
arguments, analogous to the Hibernate3 Session.

http://opensource.atlassian.com/projects/spring/browse/SPR-777

As I've replied there, I'm somewhat reluctant to add the overloaded
operations for entity names to HibernateTemplate itself. HibernateTemplate
already has quite a lot of operations on it; I'd like to avoid cluttering it
with even more overloaded methods.

Of course, like for all needs that HibernateTemplate's convenience methods
do not cover, implement a custom HibernateCallback and use the Hibernate
Session API natively. With an anonymous inner class, such a callback is
straightforward to implement, but of course more verbose than a one-line
convenience operation call.

It's worth pointing out that there is an alternative now, enabled by
Hibernate3's use of unchecked exceptions: direct Hibernate Session access
via SessionFactoryUtils.getSession - if you can live with Hibernate3's
unchecked HibernateException's getting thrown to callers.

If you can guarantee to always execute within a transaction in such a
scenario, you don't even need to call
SessionFactoryUtils.closeSessionIfNecessary, which allows you to write
straightforward direct Session access code.

public class MyDao extends HibernateDaoSupport {

  public MyObject loadMyObject(String id) throws HibernateException {
    return (MyObject) getSession(false).load("myEntityName", id);
  }
}

The advantage of this style is that there is no wrapping of the Hibernate
Session: It's plain Hibernate Session access; the only thing Spring provides
is a lookup method that returns the Spring-managed transactional Hibernate
Session.

The disadvantage is, of course, that HibernateExceptions will get thrown
as-is, which means that callers have to be coded against Hibernate-specific
exceptions when trying to handle them. If those exceptions don't get handled
explicitly in business facade code, exception mappings in error views are
affected.

At least callers don't need to declare the formerly checked
HibernateException anymore: If they don't care about exceptions thrown by
the DAO, they can simply let the now (since Hibernate3) unchecked
HibernateException through - without explicitly catching it or declaring it
in the "throws" clause.

An interesting question is whether we should always strictly recommend the
HibernateTemplate/DataAccessException approach, even in case of many custom
HibernateCallbacks. In some applications, people might not care about
generic data access exceptions, so Hibernate3's unchecked exceptions might
be acceptable...

The same applies to JDO: unchecked JDOExceptions might be acceptable as DAO
exceptions in some scenarios. Like in the Hibernate3 case, this is only
really interesting if always executing within a transaction, though: else,
DAO implementations would get cluttered with try-finally blocks for closing
resources.

Thoughts? Opinions?

Juergen