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