Si, me refería a las abstracciones.
On 12 abr, 11:02, Fabio Maulo <[email protected]> wrote:
> 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
-~----------~----~----~----~------~----~------~--~---
