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

[Artur K. <kar...@as...>]

Juergen Hoeller wrote:

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

It's 15 new methods - that's right. But these are very usefull methods.
Please add these methods just for sake of consistency. I think, in two
years, when HB3+ becomes mainstream and people will be using new features,
there will be a lot of questions about that. Don't You think?

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

That's exactly my point. It's relativelly inconvinient and verbose. Don't
get me wrong, but - 'there is a lot of methods in HibernateTemplate
already' - is not good excuse ;).

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

But as You say - You have to deal with hibernate exceptions. It's not easy
nor elegant. Users love Spring because it wraps these exceptions ang giving
them better, meaningfull versions. And You can easly switch from HB to JDO
without rewriting Your exception handling code.

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

And that's really big disadvantage.

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

IMHO You should add these methods just for sake of consistency.

Artur

-- 
,,Wine, jako emulator Windows...'' -- WO, pcoa
,,As Wine's name says: "Wine Is Not an Emulator"'' -- WineHQ, FAQ