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

[Keith D. <ke...@in...>]

Just a general my 2c comment on this:

In general, I think adding convenience methods to _implementations_ won't
introduce confusion so long as those methods add value in the typical cases
and are clearly documented.  I think if anything they'll actually help
promote usage consistency, as mentioned.

On the other hand, I think adding a bunch of convenience methods to an
interface is typically not a good thing (which would be HibernateOperations
in this case?), as it places unnecessary-brittle burden on implementers.  

We've seen this issue addressed elegantly in other parts of Spring.  Take
the MessageSource interface, for example.  MessageSource is base interface
that may be easily wrapped in a MessageSourceAccessor convenience accessor
implementation.  From there usage is a snap, and MessageSource
implementations don't have to change.

I recently had to deal with this same issue in web.flow and adopted a
similar strategy (simple interface, rich convenience wrapper), which I
thought worked well.

Keith 

-----Original Message-----
From: spr...@li...
[mailto:spr...@li...] On Behalf Of
Artur Karazniewicz
Sent: Monday, March 14, 2005 1:08 PM
To: spr...@li...
Subject: [Springframework-developer] Re: Hibernate3 entity names, direct
Session access

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



-------------------------------------------------------
SF email is sponsored by - The IT Product Guide
Read honest & candid reviews on hundreds of IT Products from real users.
Discover which products truly live up to the hype. Start reading now.
http://ads.osdn.com/?ad_id=6595&alloc_id=14396&op=click
_______________________________________________
Springframework-developer mailing list
Spr...@li...
https://lists.sourceforge.net/lists/listinfo/springframework-developer