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

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

Good point, the criteria should be how often they are likely to be used, not
that they are new. Agreed on that. So, how often are they likely to be used?
:-)

What's your opinion on direct Session access, Colin? The same option exists
not only with JDO, but also with the forthcoming EJB3 EntityManager: All
those could be accessed directly if one accepts the non-generic (but at
least unchecked) data access exceptions getting thrown. Spring would
essentially just provide DAO wiring and transaction management here, which
some people might like: no wrapping of the perfectly good Hibernate (or JDO
or EntityManager) API going on there ;-)

Juergen


-----Original Message-----
From: spr...@li...
[mailto:spr...@li...]On Behalf
Of Colin Sampaleanu
Sent: Monday, March 14, 2005 5:17 AM
To: spr...@li...
Subject: Re: [Springframework-developer] 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.
>
>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
>
>
I think the decision on whether to add the new methods should not be
based oin whether there are already too many methods, but rather on how
often the new ones would be used. If the new Hibernate3 Session
interface methods are going to be used a lot by the average yuser (as
much as the class based ones) then they probably belong. On the other
hand, if they are going to be used a lot less, then the callback is ok
(IMHO). But just because they're new shouldn't be the real criteria...



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