Lo de escribir más código... yo confío en que vayan saliendo librerías como BeanLib en java, que permitan "mapear" los mensajes a entidades siguiendo unas reglas definidas.
Desde luego que si, se necesita más código, pero también tiene su recompensa. Si trabajas con DTOs puros, estás trabajando mediante un sistema de mensajes... puedes colocar fácilmente luego esos mensajes en colas MSMQ (tenemos un sistema de invocación asíncrona controlada basado en esta característica), o puedes integrar tus servicios más fácilmente en una SOA. O simplemente publicarlos en SOAPs públicas. Tu aproximación mediante las apis de "reflection" es muuuuy interesante y si tienes código para ver estaría genial... pero cómo propagas los cambios a tu dominio una vez te devuelve el cliente el grafo de objetos modificado? osea, cómo lo "merge"'as? y sobre todo, cómo verificas y validas los cambios que te propone el cliente? si no hay automatismo ahí, con tu solución realmente solo ganas en sentido servidor->cliente... En cualquier caso, tu método "Unproxy" es opensource? :))) 2007/1/29, "Andrés G. Aragoneses [ knocte ]" <[EMAIL PROTECTED]>: > > 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 -~----------~----~----~----~------~----~------~--~---
