Francisco A. Lozano escribió:
> Creo que hay más motivos por los que pasar entidades fuera del
> contexto local de la aplicación no es una buena idea, incluso con un
> modelo de dominio completamente anémico como los tuyos. Por ejemplo,
> la seguridad... Compruebas que el cliente haya modificado únicamente
> lo que tu le dejes, antes de hacer un update, (o saveOrUpdate, o
> merge, o lo que sea) con el objeto que te viene de fuera? O te fías
> del "cliente"? (grave fallo de seguridad, en tal caso). Aparte,
La seguridad la baso en sesiones, pasando continuamente un token de
verificación en cada llamada (aunque esa parte no la he diseñado yo, la
tendré que revisar...).
> serializas los proxies de las propiedades lazy-loading? o qué
> serializas?
Los proxies se quitan (se sustituyen con objetos con un atributo
NeedLoad a true). Las colecciones no recuperadas se dejan a null
(distinguiéndolas de las vacías porque éstas últimas no son null pero no
tienen ítems). Todo esta transformación la hace el método basado en
"reflexión".
> Eso de "Limpiar" objetos Nhibernate mediante reflexión es una
> grandísima idea y me gusta mucho, he hecho algún intento en el pasado
> (intentando pasarle objetos Hibernate a Google Web Toolkit, por
> ejemplo :) pero no lo he usado nunca en nada serio. Cómo defines los
> fetch-plans? es decir, hasta qué profundidad del grafo de objetos
> preparas para ser transferido? Y cómo le das esa info a la capa de
> reflexión? Xquery o algo así?
Al principio estaba utilizando una "meta-técnica", que consistía en que
el lado del servidor tenía las 4 típicas operaciones CRUD que recibían o
devolvían objetos (además del tipo de objeto que se quería
enviar/recibir, al igual que ocurre con el método Load<> genérico de la
ISession de NHibernate). En el caso de las recogidas, también recibía un
número que indicaba el nivel de profundidad que debía traerse de las
colecciones.
Sin embargo, este método empezó a darme problemas por dos cuestiones:
- Era más difícil controlar la seguridad, como tú ya has hecho notar más
arriba.
- Había ocasiones en las que se requerían diferentes niveles de
profundidad en colecciones distintas de los objetos.
Por lo tanto, ahora se programa un método/llamada por cada operación que
quiera efectuarse en el lado del controlador, en el cual el servidor
recorre el objeto por sus colecciones hasta los niveles que sepa que va
a necesitar el cliente. El método Unproxy luego lo único que hace es
limpiar el objeto de manera que sólo envía lo que se ha recuperado desde
la BDD y no más (puesto que lo primero que hace el Unproxy antes de
recorrer el objeto es desconectar la sesión, para no provocar más
consultas bajo demanda).
> Creo que escupir entidades completas por un canuto de red está mas
> cerca de arquitecturas cliente-servidor de-antes que de arquitecturas
> 3(omás)-tier modernas.
>
> Prefiero limitar los DTOs a
> la-información-que-necesita-ese-caso-de-uso-y-nada-más en vez de ir
> pasando grafo de entidades completo que requiera o pueda requerir + la
> habilidad de lazy loading remoto. Así, los "mensajes" que atraviesan
> la red están predefinidos (representaciones de DTOs serializados en
> XML o en binario o en lo que corresponda), lo cual es mucho más
> correcto desde el punto de vista de un protocolo de red.
Mmmm, es posible que sea más elegante. Pero desde luego tienes que
escribir mucho más código ;)
Saludos,
Andrés [ knocte ]
--
--~--~---------~--~----~------------~-------~--~----~
Para escribir al Grupo, hágalo a esta dirección:
[email protected]
Para más, visite: http://groups-beta.google.com/group/NHibernate-Hispano
-~----------~----~----~----~------~----~------~--~---
