Solo para aclarar los tantos...La UoW es la session de NH, no hay ninguna otra UoW implementada en ningún FW que use NH.
El 9 de abril de 2009 11:33, JoseFR <[email protected]> escribió: > > Gustavo, dejame decirte antes que nada que creo que subestime el tema > del manejo de la session, aunque creo que ya estoy encaminado. > He decidido por el momento el camino mas facil, no voy a soportar long > conversation, aunque estuve mirando un poco burrow. > Me gusta este approach: > * There is no Session (That is, some sort of client session) > * A service implementation is created and destroyed for every call > * The scope of a service instance is the same as the scope of a > request is the same as the scope we chose for the NHibernate Session. > > http://realfiction.net/?q=node/167 > > > El proyecto incluira las siguientes componentes: > Silverligth, WCF, comunicandose a partir de DTO's (como dijimos > antes), > -Fluent Nhibernate automappings. > -Nhibernate Linq. > -NHV; con alguna integración automatica a silverlight, a proposito de > esto, creo que la comunidad debería adelantarse a los hechos > silverlight 3 incluye un framework de validaciones similares que se > integra con la ui. Quizas este proyecto sirva de experiencia. > -Castle; como IoC, estoy usando la WCF Facility. > > -Por ahora no voy a crear ni utilizar ninguna implementación > existente de unitofwork, y manejar directamente la sesion de > nhibernate; por dos razones crear una implementación me implica un > tiempo, y las implementaciones que ya hay mas o menos serias > Rhino.Commons y una nueva NCommon me obligan a usar sus > implementaciones de Repositorio, por un lado el repositorio de > Rhino.Common no parece muy Linq Friendly, incluye mil funciones > FindAll.. basadas en el nhibernate query generator de ayende, creo que > Linq reduce todo eso a muy poco. Ademas rhino.common tiene > quinicientas dependencias con otras cosas y no me gustaría agregar > tanto ruido. NCommons lo veo mas simple aunque me llamo la atención > que su repositorio no tuviera un simple get by id. Si bien en las > implementaciones concretas podría hacerlo a traves de linq.. No me > convence! lo veo verde. Como se dijo antes el UnitOfWork no es parte > del application block pero el repositorio de cierta forma si. Alguna > otra sugerencia en este aspecto? > > -Cuasi-anecdótico dado que rebasa el alcance, del foro mencionar que > para la parte de silverlight tengo pensado usar caliburn. Pero no > estoy seguro de eso todavía. > > > > > On 7 abr, 11:13, JoseFR <[email protected]> wrote: > > Si entendí bien. > > > > Apenas tengo algo andando hago un post en mi blog con el fuente y > > pongo el link aca. > > > > On 7 abr, 09:41, Gustavo Ringel <[email protected]> wrote: > > > > > Hi Jose, no me referia a que era OT cuando dije sacar Silverlight, sino > en > > > el sentido de tratar de evitar en lo maximo posible que la tecnologia > de > > > presentacion te influya en la decision de que servicios brindar y mucho > > > menos en la forma de desarrollar el acceso a datos. > > > > > A mi me parece interesante de todos modos que cada uno plantee como > resolvio > > > y sus dudas aca, y yo trato de compartir lo que he hecho y leido... > > > > > Cuando tengas una infraestructura andando estas invitado a compartir > aca > > > como resolviste, a generar algun codigo de ejemplo que allane camino a > > > otros...o compartir tus dudas de porque no seria la mejor opcion la que > > > arrancaste y como pensas que habria que mejorarla, que es lo que me > pasa a > > > mi en general apenas termino :). > > > > > Gustavo. > > > > > 2009/4/7 JoseFR <[email protected]> > > > > > > Bueno Gustavo, hasta ayer no quería.. pero creo que ya me > convenciste. > > > > Pensandolo bien me parece que va a ser mejor por ese lado... > > > > Y lo de silverlight estaría de mas en el titulo, y en menor medida > > > > nhibernate y ups.. este es el foro de nhibernate. > > > > Bueno como siempre muchisimas gracias y perdon si fue medio OT. > > > > > > On 7 abr, 06:03, "Francisco A. Lozano" <[email protected]> wrote: > > > > > Comunicación entre contextos de ejecución bien diferenciados -> > Mensajes > > > > -> DTO. > > > > > > > Francisco A. Lozano > > > > > > > 2009/4/7 JoseFR <[email protected]>: > > > > > > > > La pregunta es facil, pero la respuesta me ha parecido muy > polemica > > > > > > entre todos los foros. > > > > > > Lo que quisiera saber es cuales serían las implicaciones y que > > > > > > problemas podría tener en caso de querer plantear una > arquitectura > > > > > > teniendo en cuenta lo siguiente: > > > > > > -Antes que nada yo tengo el control de los dos extremos de la > > > > > > aplicación y lo que se exporta por WCF se consume en un solo tipo > de > > > > > > cliente (cliente silverlight). > > > > > > -El dominio tiene clases simples, yo quiero que todo lo que envíe > por > > > > > > el cable se serialize, en algunos casos generaré DTO's pero por > lo > > > > > > general NO. > > > > > > -No quiero invadir el dominio con atributos que digan que > serializar y > > > > > > que no, para ello estuve leyendo este post que comenta sobre una > nueva > > > > > > feature del framework 3.5 SP1. ( > http://www.pluralsight.com/community/ > > > > > > blogs/aaron/archive/2008/05/13/50934.aspx). > > > > > > > > (Sacando el tema del manejo de la sesión en WCF y el lazyload.) > > > > > > > > También quisiera saber si existe alguna buena alternativa a WCF > para > > > > > > este caso? > > > -- 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 -~----------~----~----~----~------~----~------~--~---
