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

[Cameron B. <ca...@da...>]

Yeah, the autowire looks handy for those sort of cases.. I was just 
reading up on it today.. since I want to use it to autowire xwork 
actions... see my other post about this one.

Cheers,

Cameron

Colin Sampaleanu wrote:

> 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
>>
>>
>
>
>
>
> -------------------------------------------------------
> This SF.net email is sponsored by: The SF.net Donation Program.
> Do you like what SourceForge.net is doing for the Open
> Source Community?  Make a contribution, and help us add new
> features and functionality. Click here: http://sourceforge.net/donate/
> _______________________________________________
> Springframework-developer mailing list
> Spr...@li...
> https://lists.sourceforge.net/lists/listinfo/springframework-developer