Re: [Springframework-developer] Question about need for DAo's or Business Objects to keep a session factory refrence

[Colin S. <col...@ex...>]

Not quite, but you can use Spring's autowire support. That is, your 
mapper/dao beans in the app context would be set to autowire, and could 
be fed the Session Factory instance without you actually having to 
specify it. I generally don't use autowire, preferring to specify 
dependencies directly, but in this case, when you might have 10-30 
mappers taking the same parameter, it should work nicely. Here's an 
excerpt from the Spring app context dtd describing the autowire stuff:

<!ATTLIST bean dependency-check (none|objects|simple|all) "none">

<!--
    Optional attribute controlling whether to "autowire"
    bean properties. This is an automagical process in which bean references
    don't need to be coded explicitly in the XML bean definition file,
    but Spring works out dependencies.
   
    There are three modes:
   
    1. no
    The traditional Spring default. No automagical wiring. Bean references
    must be defined in the XML file via the <ref> element. We recommend this
    in most cases as it makes documentation more explicit.
   
    2. byName
    Autowiring by property name. If a bean of class Cat exposes a dog 
property,
    Spring will try to set this to the value of the bean "dog" in the 
current
    factory.
   
    3. byType
    This is like the PicoContainer default, in which there must be exactly
    one bean of the property type in the bean factory. If there are 0 or
    more than one, a fatal error is raised, and you can't use byType 
autowiring for
    that bean.
    This makes bean factories simple to configure for small namespaces,
    but doesn't work as well as standard Spring behaviour for
    bigger applications.
   
    Autowire behaviour can be combined with dependency checking, which will
    be performed after all auto wiring has been completed.
-->
<!ATTLIST bean autowire (no|byName|byType) "no">


So in the case of using HibernateDaoSupport as a base for your mappers, 
you would autowire (by explicit name or by type) the property called 
'sessionFactory' for those mappers (which they just inherit from 
HibernateDaoSupport).

Regards,
Colin



Cameron Braid wrote:

> Thanks for y our prompt reply.
>
> Yeah, that all makes sense.
>
> In regards to mapping for an abstract class - is it possible to 
> specify a mapping that gets inherited automatically, based on the 
> class hierarchy
>
> i.e. Map the HibernateDaoSupport.sessionFactory property to name 
> "mySessionFactory", and then any class that extends 
> HibernateDaoSupport inherit that mapping ?
>
> Thanks again.
>
> Cameron.
>
> Colin Sampaleanu wrote:
>
>> Cameron Braid wrote:
>>
>>> I am just beginning to use the Spring framework, and so far I am 
>>> very impressed.
>>>
>>> One thing that I don't quite understand is the mandatory requirement 
>>> for each DAO and BO (Business Object) to support the 
>>> set/getSessionFactory method.
>>>
>>> The reason that I say it is mandatory is because the only way to 
>>> obtain the current session (as far as I know) is to use 
>>> SessionFactoryUtils.getSession(SessionFactory...).  This means that 
>>> each DAO/BO requires a setSessionFactory property to be able to be 
>>> passed it from the spring container.  This also requires that each 
>>> DAO/BO to be configured to bind the SessionFactory instance within 
>>> the applicationContext.xml
>>>
>>> What I would think would be a simple and quite common use case would 
>>> be for an app to require only one session factory. Therefore I think 
>>> that the SessionFactoryUtils, and related classes , could use a 
>>> static field to store the 'default' session factory.
>>>
>>> Has something like this been considered ?
>>> Do you think that this is a good or a bad idea ?
>>>
>> Cameron,
>>
>> To clarify, your business objects would generally do not need to have 
>> a setSessionFactory method. They would need setters for one or more 
>> Mapper/DAO objects, and those Mapper/DAO objects would need the 
>> setSessionFactory method.
>>
>> As for the idea of having the Mapper/DAO objects not need the session 
>> factory parameter, and getting it from a singleton of some sort, that 
>> approach would work for some use cases, but using a singleton like 
>> this is just not very clean. It becomes harder to test code in 
>> isolation, and usually locks you into the singleton approach.
>>
>> You are at most going to declare each mapper/dao once in the 
>> application context. Giving it the session factory paramter is not a 
>> big deal. In terms of the actual code in the mapper/dao to support 
>> this, this can be provided by an abstract base class, and in fact 
>> Spring has such a class (for Hibernate) called HibernateDaoSupport.
>>
>> Regards,
>> Colin
>