De todas formas estaba mirando los ejemplos de Gustavo y, como no me podia esperar diversamente, usó el mismo Model sea para WCF que para WinForm.Tal vez tendriamos que hacer algo mas complejo. Estamos pensando de usar http://www.codeplex.com/ChinookDatabase para todos los ejemplos.
Creo que Alex pronto haga el ejemplo para CpBT con MonoRail y ChinookDatabase (por ahora hay otro ejemplo de CpBT con MonoRail). El 13 de abril de 2009 17:00, Fabio Maulo <[email protected]> escribió: > Me parece que tendremos que agregar pronto uNhAddIns.ServiceModel así eso > tambien estará cocinado. > > El 13 de abril de 2009 16:36, JoseFR <[email protected]> escribió: > > >> Perdón justamente en el link que puse dice que para accder al context >> hay que setear el servicio wcf con compatibilidad asp.net. >> >> On 13 abr, 16:25, JoseFR <[email protected]> wrote: >> > Fabio lo que no entiendo es dos cosas: >> > 1-¿Porqué insistis en escribir atar con dos T? (me imagino el porque) >> > 2-El WebSessionContext utiliza HttpContext, incluso hablando de una >> > aplicación WCF hospedada en IIS no tengo acceso al context este, por >> > eso me vi obligado a utilizar OperationContext y guardar la session >> > como una extension. ( >> http://msdn.microsoft.com/en-us/library/aa702682.aspx >> > ). Siento que estoy perdiendo de vista algo. >> > >> > On 13 abr, 16:13, Fabio Maulo <[email protected]> wrote: >> > >> > > Aclaro que te pregunto porque si usas session-per-request con >> > > el NHibernate.Context.WebSessionContext y un module que haga el >> Bind/Unbind >> > > en el begin/end request alcanza. >> > > Tabien se puede usar >> uNhAddIns.Web.SessionEasier.Contexts.WebSessionContext >> > > o >> > > uNhAddIns.Web.SessionEasier.Contexts.ExtendedWebSessionContext >> > >> > > El segundo permite manejar session-per-conversation pero sin tener en >> cuenta >> > > el problema que genera la abertura de Tabs en lugar que nueva >> instancias de >> > > browser. >> > >> > > Para ser claro... >> > > Para manejar session-per-request o session-per-conversation (a la >> manera de >> > > Castle facility) no hace falta pegar todos los DAO a Castle. >> > >> > > CpBT es mucho mas complejo de session-per-request o >> session-per-conversation >> > > y sirve para delegar el manejo de sessiones de persistencia a un >> estrato >> > > conocido (model o presenter/controler). >> > > La implementación de CpBT en uNhAddIns no solo NO te obliga a que tus >> DAOs >> > > conozcan quien maneja la session si no que tampoco te obliga a usar >> Castle >> > > como AOP. >> > >> > > Si programas SIN attar tus DAOs/Repository a algo mas que no sea NH te >> > > permite cambiar de estrateguia sin tocar nada (a parte de tener todo >> lo que >> > > brinda la SessionFactory). >> > >> > > El 13 de abril de 2009 15:38, Fabio Maulo <[email protected]> >> escribió: >> > >> > > > 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 >> >> >> > > > -- > 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 -~----------~----~----~----~------~----~------~--~---
