En winforms yo utilizo el patrón MVP Supervising Controller el cual lo explico aca: http://jfromaniello.blogspot.com/2010/11/mvp-patron-supervising-controller-para.html <http://jfromaniello.blogspot.com/2010/11/mvp-patron-supervising-controller-para.html>y la sessión de nhibernate la manejo mediante el patrón CpBT a veces en app services, y a veces directamente sobre el presenter, siempre con AOP.
Para hacerlo a nivel de presenter necesité hacer AOP en metodos privados, por lo cual use postsharp y publique el código en unhaddins.Postsharp Un ejemplo simple que twittie hace un tiempo es este: https://gist.github.com/341790 <https://gist.github.com/341790>Lo que dijo nelo de : -no compartir objetos entre sesión -no compartir sesión entre casos de uso Estoy 100% de acuerdo. Para la comunicación de datos entre diferentes casos de uso, utilizo event aggregator: http://jfromaniello.blogspot.com/2010/04/event-aggregator-example.html <http://jfromaniello.blogspot.com/2010/04/event-aggregator-example.html> http://jfromaniello.blogspot.com/2010/04/event-aggregator-with-reactive.html <http://jfromaniello.blogspot.com/2010/04/event-aggregator-with-reactive.html> http://jfromaniello.blogspot.com/2010/07/event-aggregator-subscriptors.html <http://jfromaniello.blogspot.com/2010/07/event-aggregator-subscriptors.html>Aunque ahora también he empezado a utilizar en silverlight otro patrón que se llama Subject/Conductor, con una idea muy similar: http://www.jeremydmiller.com/ppatterns/Default.aspx?Page=ScreenActivationLifecycle&AspxAutoDetectCookieSupport=1 <http://www.jeremydmiller.com/ppatterns/Default.aspx?Page=ScreenActivationLifecycle&AspxAutoDetectCookieSupport=1>A lo que voy es que uso datos simples, nunca enviaría un entidad de negocio desde un caso de uso a otro. El 26 de noviembre de 2010 02:27, Nelo Pauselli <[email protected]>escribió: > algunos puntos que yo tengo en cuenta en estos casos son: > > 1) Los objetos (y sus propiedad) que son leidos y guardados en una > session solo son visibles dentro de la session antes de hacer el > flush. mmm a ver si me explico mejor en código: > > session0.Save(new Persona {Nombre = "Original" }); > > var p1 = session1.Get<Persona>(id); > p1.Nombre = "Otro"; > > var p2 = session2.Get<Persona>(id); > Assert.AreEqual("Original", p2.Nombre); > > var p1bis = session1.Get<Persona>(id); > Assert.AreEqual("Otro", p1bis.Nombre); > > session1.Flush(); > > var p3 = session3.Get<Persona>(id); > Assert.AreEqual("Otro", p3.Nombre); > > es decir que, antes de hacer el Flush() los cambios solo son visibles > utilizando la misma session, luego del Flush están disponibles para > todas las sessions. > Pienso que esto debería ayudarte a saber si tenés que usar la misma > session o no en dos forms, para mi la conclusión es que una misma > session no se debería usar en 2 casos de uso (unit of work, etc) > diferentes o dos instancias del mismo caso de uso. > > 2) Luego, y en especial para winforms, la pregunta sería si vas a > trabajar con objetos del negocio bindeados a los controles o vas a > manejar un esquema de ApplicationServices y DTOs para la UI. > > - Si vas por la opción de los DTOs pienso que alcanzaría con manejar > una session per call a nivel de ApplicationServices, > - Si vas por la opción del binding (aspecto muy interesante en > winforms) se me ocurren dos opciones ahora, al principio de cada > método del form seteas la CurrentSession (sessions manejadas por > hilos) y antes de salir del método seteas como current la anterior o > hacés esto mismo con AOP a nivel de tu "controller", claro que con > esto no podrías poner lógica de negocio en los forms, pero hasta > quizás sea bueno. ;) > > saludos. > nelo > > > 2010/11/25 Nestor Rodriguez <[email protected]>: > > Este es un buen articulo, te lo recomiendo : > > http://msdn.microsoft.com/en-us/magazine/ee819139.aspx > > Saludos, > > Nestor Rodriguez > > > > 2010/11/25 tolemaC <[email protected]> > >> > >> Pues el problema viene al decidir una estrategia de manejo de sesión > >> en WinForm, si usar una sesión por ventana o hacerlo por cada proceso > >> de negocio, realmente el problema viene cuando un proceso de negocio > >> llama a otro, no es facil saber si hay una sesión activa, si hay que > >> abrir otra o coger la actual. También me gustaría liberar al negocio > >> del uso de la sesión, ... en fin ese tipo de cosas. > >> > >> On 24 nov, 20:42, José F. Romaniello <[email protected]> wrote: > >> > El 24 de noviembre de 2010 16:02, tolemaC <[email protected]> > escribió: > >> > > >> > > ¿Conversation-per-Business-Transaction es la respuesta al problema > con > >> > > las sesiones? > >> > > >> > Para contestarte esto necesitamos que nos digas cual es tu problema > con > >> > el > >> > manejo de sesiones. > >> > >> -- > >> Para escribir al Grupo, hágalo a esta dirección: > >> [email protected] > >> Para más, visite: http://groups.google.com/group/NHibernate-Hispano > > > > -- > > Para escribir al Grupo, hágalo a esta dirección: > > [email protected] > > Para más, visite: http://groups.google.com/group/NHibernate-Hispano > > -- > Para escribir al Grupo, hágalo a esta dirección: > [email protected] > Para más, visite: http://groups.google.com/group/NHibernate-Hispano > -- Para escribir al Grupo, hágalo a esta dirección: [email protected] Para más, visite: http://groups.google.com/group/NHibernate-Hispano
