Muy bien...Para mi el concepto es bastante simple:
Si yo uso IoC e DI para no atar mi codigo a algo especifico menos quiero
atarlo al framework de IoC/DI/AOP.

Por ese motivo, por ejemplo,
- uNhAddIns no tiene referencia a nada mas que NH y sus necesidades;
- uNhAddIns.Adapters solo usa System
- uNhAddIns.Web solo depende de uNhAddIns y lo necesario de .NET
- en los ejemplos tratamos de usar CommonServiceLocator.

Con la ultimas modificaciones (hoy) tambien se puede evitar el uso
de uNhAddIns.Adapters e injectar los metadata desde afuera (pronto va a ver
una Fluent/Programmatic configuration siempre no ligada a un IoC/DI/AOP
framework especifico).


El 13 de abril de 2009 16:09, JoseFR <[email protected]> escribió:

>
> Muchas gracias Fabio y German. German; creo que en el ejemplo que me
> pasaste la otra vez tenía algo de eso ya (o al menos la intención).
> Por ahora estoy evitando usar todo lo de castle, creo que mientras mas
> limpio lo pueda mantener mejor. Una razón que tengo para esto es que
> estoy trabajando con los trunk y voy hacer un despiole barbaro. Hasta
> ahora lo poco que estoy usando de castle (el container y la wcf
> facility) tienen 0 relación con nhibernate.
>
> On 13 abr, 15:38, Fabio Maulo <[email protected]> wrote:
> > Que pattern de session management estas usando ?
> >
> > El 13 de abril de 2009 15:27, Germán Schuager <[email protected]
> >escribió:
> >
> >
> >
> > > Si, es verdad, pero como no tengo pensado cambiar Castle por otra cosa
> el
> > > tema de que mis DAOs dependan de dicho framework no lo veo como un
> problema;
> > > y acerca del otro punto, también es cierto que no puedo usar
> ISessionManager
> > > para abrir una stateless session (entre otras cosas), lo cual tampoco
> es un
> > > problema porque en el momento que lo necesite inyecto ISessionFactory
> donde
> > > corresponda y listo (todavía no lo he necesitado).
> >
> > > De todas formas estoy de acuerdo que si con SessionFactory alcanza no
> hay
> > > necesidad de meter otra cosa en el medio.
> >
> > > Usar NH facility me brinda una forma sencilla de manejar la
> > > instancia/contexto del objeto que me provee las sessions a través del
> > > contenedor y si puediese hacer lo mismo sin ligar mis DAOs a Castle es
> muy
> > > probable que iría por ese camino, es por eso que en el poco tiempo
> libre que
> > > tengo estoy mirando el trabajo que hicieron con Gustavo en uNhAddins y
> tus
> > > posts sobre CpBT para ver como resolvieron esto.
> >
> > > 2009/4/13 Fabio Maulo <[email protected]>
> >
> > >> El 13 de abril de 2009 15:01, Germán Schuager <[email protected]
> >escribió:
> >
> > >> Hola José, yo también estoy trabajando en un escenario similar y opté
> por
> > >>> la opción 2; el objeto que inyecto es un ISessionManager de la NH
> Facility
> > >>> de Castle... como también estas usando Castle, quizá te sirva pegarle
> una
> > >>> mirada.
> > >>> Este camino también te da soporte para utilizar los atributos de
> > >>> Castle.Services.Transaction para delimitar las transacciones de forma
> > >>> declarativa.
> >
> > >> y ATTA todos tus DAO/Repository a ISessionManager de Castle.
> >
> > >> mientras que la opción 1 los atta solo a NHibernate y te permite tener
> la
> > >> SessionFactory para implementar "cosas" un poco mas avanzadas como
> > >> StateLessSession, OpenSession afuera de la CurrentSession, Evict de
> cache
> > >> etc.
> >
> > >> --
> > >> Fabio Maulo
> >
> > --
> > Fabio Maulo
> >
>


-- 
Fabio Maulo

--~--~---------~--~----~------------~-------~--~----~
Para escribir al Grupo, hágalo a esta dirección: 
[email protected]
Para más, visite: http://groups.google.com/group/NHibernate-Hispano
-~----------~----~----~----~------~----~------~--~---

Responder a