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