consulta sobre buen diseño

[Gustavo Ringel]

Hi, tengo un lio que siempre que empiezo una nueva aplicacion, dudo como
diseñar correctamente y nunca llego a algo concreto.

Hoy en dia en mi aplicacion cree DTO's, que tienen la version de las
business entities como las ve el cliente. Si bien mi aplicacion no esta
distribuida, los servicios igual devuelven y reciben DTO's, la idea en su
momento era por un lado no mandar informacion a las vistas que no les
interesa y ademas posibilidad de escalar a WCF o Web Services o lo que fuera
con facilidad.

Esto quiere decir que para business entity tengo que transformar la entidad
en DTO y viceversa.

Ahora estoy escribiendo una nueva aplicacion y nuevamente me veo obligado a
duplicar informacion cuando la aplicacion cliente y servidor por ahora son
la misma, y por razones de ambiente tampoco creo que trabaje WCF/Remoting o
ninguna alternativa...

Basicamente salvo que no tiene nada que hacer con la informacion extra,
podria leer un objeto nhibernate, clonarlo para desconectarme del proxy y
devolver el mismo tipo de objeto al cliente. Cuando el cliente me manda un
objeto de vuelta podria hacer Load del id y trabajar con el objeto
NHibernate...

Claramente esta ultima opcion parece muy sucia a nivel del codigo. Ahora la
pregunta es que hacen ustedes...tambien si la session de nhibernate la
manejan a nivel de servicios como hacen para trabajar con transacciones
multiservicio...(TransactionScope?)


Gracias.

Gustavo.

--~--~---------~--~----~------------~-------~--~----~
Para escribir al Grupo, hágalo a esta dirección: NHibernate-***@googlegroups.com
Para más, visite: http://groups.google.com/group/NHibernate-Hispano
-~----------~----~----~----~------~----~------~--~---

[Angel "Java" Lopez]

Hola gente!

Algunos comentarios, algo alejados pero relaciones a la pregunta original:

- Creo que el tema de que "vuelvan" DTOs hasta el dominio que son representacion casi igual de los objetos del dominio, casi solo se da en los casos de ABM (altas, bajas y modificaciones).
- Trato de imaginar un dominio, donde el NHibernate es apenas el encargado de la persistencia, ortogonal al dominio, idealmente transparente.
- El dominio es un "bicho" al que le enviamos mensajes y comienza a trabajar. El mensaje llega desde otro lado, quizas desde la presentacion. Caso tipico: en un sistema de consorcios, le enviamos a calcular la liquidacion de un consorcio. No le enviamos desde la presentacion al dominio un consorcio: apenas le enviamos algun identificador, y un rango de fechas de gastos a liquidar (espero que se entienda el ejemplo, fuera de Argentina)
- A presentacion van y vuelven mensajes, adecuados al paso(s) del caso de uso que tengamos entre manos. Si los DTOs se deben adecuar a la forma de transporte o exposicion (p.ej., tener un [DataContract] en WCF, o tener [Serializable] en Remoting), es un tema tecnologico que a dominio, y su persistencia en NHibernate, apenas le deberia importar. Si no hay tema de transporte remoto, igual me gustaria pensar en mensajes, adecuados al caso de uso, y si envio un objeto de dominio, tener todo el "awareness" de que estoy haciendo eso, por alguna razon tactica o pereza.

A veces, veo muchas preguntas sobre el uso de NHibernate, pidiendole que haga cosas que no son su responsabilidad (no digo que sea el caso de la pregunta de abajo, que apunta a otra cosa, solo queria aprovechar este mensaje para enviar esta opinion). Creo que puede pedirse algo asi, pero estar "aware", advertidos, que no es la herramienta para dar DTOs, o para clonarlos o lo que sea. Si lo usamos de esa manera, es por una razon tactica oportunista: simplificar lo que estamos haciendo, escribir menos codigo (algo que cualquier usuario de AjGenesis ni tiene que temer... ;-), y otras....

No se si aclare u oscureci.... ;-)

Nos leemos!

Angel "Java" Lopez
http://www.ajlopez.com/


----- Original Message -----
From: Gustavo Ringel
To: nhibernate-***@googlegroups.com
Sent: Sunday, December 02, 2007 12:44 PM
Subject: [NHibernate-Hispano] consulta sobre buen diseño


Hi, tengo un lio que siempre que empiezo una nueva aplicacion, dudo como diseñar correctamente y nunca llego a algo concreto.

Hoy en dia en mi aplicacion cree DTO's, que tienen la version de las business entities como las ve el cliente. Si bien mi aplicacion no esta distribuida, los servicios igual devuelven y reciben DTO's, la idea en su momento era por un lado no mandar informacion a las vistas que no les interesa y ademas posibilidad de escalar a WCF o Web Services o lo que fuera con facilidad.

Esto quiere decir que para business entity tengo que transformar la entidad en DTO y viceversa.

Ahora estoy escribiendo una nueva aplicacion y nuevamente me veo obligado a duplicar informacion cuando la aplicacion cliente y servidor por ahora son la misma, y por razones de ambiente tampoco creo que trabaje WCF/Remoting o ninguna alternativa...

Basicamente salvo que no tiene nada que hacer con la informacion extra, podria leer un objeto nhibernate, clonarlo para desconectarme del proxy y devolver el mismo tipo de objeto al cliente. Cuando el cliente me manda un objeto de vuelta podria hacer Load del id y trabajar con el objeto NHibernate...

Claramente esta ultima opcion parece muy sucia a nivel del codigo. Ahora la pregunta es que hacen ustedes...tambien si la session de nhibernate la manejan a nivel de servicios como hacen para trabajar con transacciones multiservicio...(TransactionScope?)


Gracias.

Gustavo.



--~--~---------~--~----~------------~-------~--~----~
Para escribir al Grupo, hágalo a esta dirección: NHibernate-***@googlegroups.com
Para más, visite: http://groups.google.com/group/NHibernate-Hispano
-~----------~----~----~----~------~----~------~--~---

[Gustavo Ringel]

Hi Angel, basicamente respondes. Ahora una consulta respecto a eso...segun
tu opinion digamos que en el dominio yo tengo una entidad compleja, por
decir algo "Proveedor" identificada por un ID Int32.
Supongamos que tengo varios elementos en la base asociado al proveedor, pero
mando datos a una consulta en la que paso por todos los proveedores y solo
quiero actualizar el telefono si es necesario.
El servicio seria por ejemplo GetProveedores(Algun filtro) y
SetTelefono(DTOProveedor) donde DTOProveedor seria un ID + Telefono?

Es decir, vos le revelarias al cliente que utilizas el campo ID para
identificar cuando vuelve? ese es justamente el problema que yo no logro
solucionar elegantemente, si maniana quiero cambiar a GUID la identificacion
o el tipo de datos no es suficiente para la cantidad de datos
manejados, tengo que cambiar todos los DTO, mas los servicios...

Bue, capaz que me equivoco en la direccion de lo que vos decis.

Entiendo que no es una pregunta de NHibernate directo asi que pido
disculpas, pero la idea es justamente que NHibernate sea el manejador de la
persistencia y obtencion de datos del lado del servicio y estoy buscando la
forma de comunicarme con la capa de presentacion de manera adecuada...

Gustavo.

Post by Angel "Java" Lopez
Hola gente!
- Creo que el tema de que "vuelvan" DTOs hasta el dominio que son
representacion casi igual de los objetos del dominio, casi solo se da en los
casos de ABM (altas, bajas y modificaciones).
- Trato de imaginar un dominio, donde el NHibernate es apenas el encargado
de la persistencia, ortogonal al dominio, idealmente transparente.
- El dominio es un "bicho" al que le enviamos mensajes y comienza a
trabajar. El mensaje llega desde otro lado, quizas desde la presentacion.
Caso tipico: en un sistema de consorcios, le enviamos a calcular la
liquidacion de un consorcio. No le enviamos desde la presentacion al dominio
un consorcio: apenas le enviamos algun identificador, y un rango de fechas
de gastos a liquidar (espero que se entienda el ejemplo, fuera de Argentina)
- A presentacion van y vuelven mensajes, adecuados al paso(s) del caso de
uso que tengamos entre manos. Si los DTOs se deben adecuar a la forma de
transporte o exposicion (p.ej., tener un [DataContract] en WCF, o tener
[Serializable] en Remoting), es un tema tecnologico que a dominio, y su
persistencia en NHibernate, apenas le deberia importar. Si no hay tema de
transporte remoto, igual me gustaria pensar en mensajes, adecuados al caso
de uso, y si envio un objeto de dominio, tener todo el "awareness" de que
estoy haciendo eso, por alguna razon tactica o pereza.
A veces, veo muchas preguntas sobre el uso de NHibernate, pidiendole que
haga cosas que no son su responsabilidad (no digo que sea el caso de la
pregunta de abajo, que apunta a otra cosa, solo queria aprovechar este
mensaje para enviar esta opinion). Creo que puede pedirse algo asi, pero
estar "aware", advertidos, que no es la herramienta para dar DTOs, o para
clonarlos o lo que sea. Si lo usamos de esa manera, es por una razon tactica
oportunista: simplificar lo que estamos haciendo, escribir menos codigo
(algo que cualquier usuario de AjGenesis ni tiene que temer... ;-), y
otras....
No se si aclare u oscureci.... ;-)
Nos leemos!
Angel "Java" Lopez
http://www.ajlopez.com/
----- Original Message -----
*Sent:* Sunday, December 02, 2007 12:44 PM
*Subject:* [NHibernate-Hispano] consulta sobre buen diseño
Hi, tengo un lio que siempre que empiezo una nueva aplicacion, dudo como
diseñar correctamente y nunca llego a algo concreto.
Hoy en dia en mi aplicacion cree DTO's, que tienen la version de las
business entities como las ve el cliente. Si bien mi aplicacion no esta
distribuida, los servicios igual devuelven y reciben DTO's, la idea en su
momento era por un lado no mandar informacion a las vistas que no les
interesa y ademas posibilidad de escalar a WCF o Web Services o lo que fuera
con facilidad.
Esto quiere decir que para business entity tengo que transformar la
entidad en DTO y viceversa.
Ahora estoy escribiendo una nueva aplicacion y nuevamente me veo obligado
a duplicar informacion cuando la aplicacion cliente y servidor por ahora son
la misma, y por razones de ambiente tampoco creo que trabaje WCF/Remoting o
ninguna alternativa...
Basicamente salvo que no tiene nada que hacer con la informacion extra,
podria leer un objeto nhibernate, clonarlo para desconectarme del proxy y
devolver el mismo tipo de objeto al cliente. Cuando el cliente me manda un
objeto de vuelta podria hacer Load del id y trabajar con el objeto
NHibernate...
Claramente esta ultima opcion parece muy sucia a nivel del codigo. Ahora
la pregunta es que hacen ustedes...tambien si la session de nhibernate la
manejan a nivel de servicios como hacen para trabajar con transacciones
multiservicio...(TransactionScope?)
Gracias.
Gustavo.

--~--~---------~--~----~------------~-------~--~----~
Para escribir al Grupo, hágalo a esta dirección: NHibernate-***@googlegroups.com
Para más, visite: http://groups.google.com/group/NHibernate-Hispano
-~----------~----~----~----~------~----~------~--~---

[Dario Quintana]

Hola, me meto en la conversa...

Entiendo por cliente, que te referís a una página Web por ejemplo, y vos
decis que necesitás mostrar el Id ? No veo por que tenés que mostrarlo, lo
podés ocultar.
Del mundo de los Id's no podemos escapar mucho, por que debemos identificar
univocamente los objetos, no hay escapatoria.
Ni siquiera en una base Orientada a Objetos como db4o, podés amañartela,
pero... siempre resulta más facil poner 1 Id y se terminó la cuestión.
Por eso, por muchos mecanismos que hagamos, si estamos trabajando con DTOs
en la presentación, la solución que escojamos, no creo que sea más facil que
el poner Ids ocultos en la presentación, creo que es la técnica más usada.

Y cuando decís que si cambiás un Id Entero (Int32), por un Guid, tenés que
cambiar muchas cosas... y te puedo decir que sí, es cierto, pero esto ya lo
debemos saber desde antes, es una de las "desventajas" de un enfoque en
capas... un cambio en una capa se verá reflejado en las otras capas,
siempre.

Por ahí leí que decis que no encontrabas un enfoque más elegante al tener
que cargar con un Load al objeto para poder hacer un update, esto es así, y
no hay una solución más elegante, NHibernate para hacer un update, el objeto
tiene que ser Persistente y no "Detachado".

Espero que se haya entendido...sino lo seguimos ;)

Saludos

Post by Gustavo Ringel
Hi Angel, basicamente respondes. Ahora una consulta respecto a eso...segun
tu opinion digamos que en el dominio yo tengo una entidad compleja, por
decir algo "Proveedor" identificada por un ID Int32.
Supongamos que tengo varios elementos en la base asociado al proveedor,
pero mando datos a una consulta en la que paso por todos los proveedores y
solo quiero actualizar el telefono si es necesario.
El servicio seria por ejemplo GetProveedores(Algun filtro) y
SetTelefono(DTOProveedor) donde DTOProveedor seria un ID + Telefono?
Es decir, vos le revelarias al cliente que utilizas el campo ID para
identificar cuando vuelve? ese es justamente el problema que yo no logro
solucionar elegantemente, si maniana quiero cambiar a GUID la identificacion
o el tipo de datos no es suficiente para la cantidad de datos
manejados, tengo que cambiar todos los DTO, mas los servicios...
Bue, capaz que me equivoco en la direccion de lo que vos decis.
Entiendo que no es una pregunta de NHibernate directo asi que pido
disculpas, pero la idea es justamente que NHibernate sea el manejador de la
persistencia y obtencion de datos del lado del servicio y estoy buscando la
forma de comunicarme con la capa de presentacion de manera adecuada...
Gustavo.

Post by Angel "Java" Lopez
Hola gente!
- Creo que el tema de que "vuelvan" DTOs hasta el dominio que son
representacion casi igual de los objetos del dominio, casi solo se da en los
casos de ABM (altas, bajas y modificaciones).
- Trato de imaginar un dominio, donde el NHibernate es apenas el
encargado de la persistencia, ortogonal al dominio, idealmente transparente.
- El dominio es un "bicho" al que le enviamos mensajes y comienza a
trabajar. El mensaje llega desde otro lado, quizas desde la presentacion.
Caso tipico: en un sistema de consorcios, le enviamos a calcular la
liquidacion de un consorcio. No le enviamos desde la presentacion al dominio
un consorcio: apenas le enviamos algun identificador, y un rango de fechas
de gastos a liquidar (espero que se entienda el ejemplo, fuera de Argentina)
- A presentacion van y vuelven mensajes, adecuados al paso(s) del caso
de uso que tengamos entre manos. Si los DTOs se deben adecuar a la forma de
transporte o exposicion (p.ej., tener un [DataContract] en WCF, o tener
[Serializable] en Remoting), es un tema tecnologico que a dominio, y su
persistencia en NHibernate, apenas le deberia importar. Si no hay tema de
transporte remoto, igual me gustaria pensar en mensajes, adecuados al caso
de uso, y si envio un objeto de dominio, tener todo el "awareness" de que
estoy haciendo eso, por alguna razon tactica o pereza.
A veces, veo muchas preguntas sobre el uso de NHibernate, pidiendole que
haga cosas que no son su responsabilidad (no digo que sea el caso de la
pregunta de abajo, que apunta a otra cosa, solo queria aprovechar este
mensaje para enviar esta opinion). Creo que puede pedirse algo asi, pero
estar "aware", advertidos, que no es la herramienta para dar DTOs, o para
clonarlos o lo que sea. Si lo usamos de esa manera, es por una razon tactica
oportunista: simplificar lo que estamos haciendo, escribir menos codigo
(algo que cualquier usuario de AjGenesis ni tiene que temer... ;-), y
otras....
No se si aclare u oscureci.... ;-)
Nos leemos!
Angel "Java" Lopez
http://www.ajlopez.com/
----- Original Message -----
*Sent:* Sunday, December 02, 2007 12:44 PM
*Subject:* [NHibernate-Hispano] consulta sobre buen diseño
Hi, tengo un lio que siempre que empiezo una nueva aplicacion, dudo como
diseñar correctamente y nunca llego a algo concreto.
Hoy en dia en mi aplicacion cree DTO's, que tienen la version de las
business entities como las ve el cliente. Si bien mi aplicacion no esta
distribuida, los servicios igual devuelven y reciben DTO's, la idea en su
momento era por un lado no mandar informacion a las vistas que no les
interesa y ademas posibilidad de escalar a WCF o Web Services o lo que fuera
con facilidad.
Esto quiere decir que para business entity tengo que transformar la
entidad en DTO y viceversa.
Ahora estoy escribiendo una nueva aplicacion y nuevamente me veo
obligado a duplicar informacion cuando la aplicacion cliente y servidor por
ahora son la misma, y por razones de ambiente tampoco creo que trabaje
WCF/Remoting o ninguna alternativa...
Basicamente salvo que no tiene nada que hacer con la informacion extra,
podria leer un objeto nhibernate, clonarlo para desconectarme del proxy y
devolver el mismo tipo de objeto al cliente. Cuando el cliente me manda un
objeto de vuelta podria hacer Load del id y trabajar con el objeto
NHibernate...
Claramente esta ultima opcion parece muy sucia a nivel del codigo. Ahora
la pregunta es que hacen ustedes...tambien si la session de nhibernate la
manejan a nivel de servicios como hacen para trabajar con transacciones
multiservicio...(TransactionScope?)
Gracias.
Gustavo.

[Carlos Peix]

Hola Gustavo,

Nota: Creo que esto es util para todos pero tambien me parece que es un OT, asi
que lo marque en el asunto.

Te cuento como pienso yo estos casos.
Los DTOs los entiendo como objetos especificos para resolver las necesidades de
comunicacion en un caso determinado. Nunca comienzo creando un DTO por cada
objeto de dominio. Eso me ha llevado a tener objetos que nunca uso y a que me
falten objetos o que no sea eficiente con los DTOs.

Entonces, en el caso que planteaste crearia un DTO especial para la "pantalla de
edicion masiva de numeros de telefono". Este DTO tendria cuatro propiedades:
CUIT (clave tributaria), Descroipcion del proveedor, tenefono actual, telefono
nuevo (inicialmente igual al actual).

Devolveria una coleccion de estos objetos desde la consulta y el cliente
editaria esos datos. Luego el cliente me envia al webservice solo los objetos
que fueron editados y el servicio haria los cambios sobre el modelo. Si esta
coleccion de telefonos editados la colocas en un objeto especial llamado (por
ejemplo) CambioDeTelefonosRequest tenes el mensaje que menciona Angel. El
servicio respondera con el correspondiente mensaje XXXX.Response y listo.

Saludos

Carlos Peix


_____

From: NHibernate-***@googlegroups.com
[mailto:NHibernate-***@googlegroups.com] On Behalf Of Gustavo Ringel
Sent: Domingo, 02 de Diciembre de 2007 05:15 p.m.
To: NHibernate-***@googlegroups.com
Subject: [NHibernate-Hispano] Re: consulta sobre buen diseño


Hi Angel, basicamente respondes. Ahora una consulta respecto a eso...segun tu
opinion digamos que en el dominio yo tengo una entidad compleja, por decir algo
"Proveedor" identificada por un ID Int32.
Supongamos que tengo varios elementos en la base asociado al proveedor, pero
mando datos a una consulta en la que paso por todos los proveedores y solo
quiero actualizar el telefono si es necesario.
El servicio seria por ejemplo GetProveedores(Algun filtro) y
SetTelefono(DTOProveedor) donde DTOProveedor seria un ID + Telefono?

Es decir, vos le revelarias al cliente que utilizas el campo ID para identificar
cuando vuelve? ese es justamente el problema que yo no logro solucionar
elegantemente, si maniana quiero cambiar a GUID la identificacion o el tipo de
datos no es suficiente para la cantidad de datos manejados, tengo que cambiar
todos los DTO, mas los servicios...

Bue, capaz que me equivoco en la direccion de lo que vos decis.

Entiendo que no es una pregunta de NHibernate directo asi que pido disculpas,
pero la idea es justamente que NHibernate sea el manejador de la persistencia y
obtencion de datos del lado del servicio y estoy buscando la forma de
comunicarme con la capa de presentacion de manera adecuada...

Gustavo.

On Dec 2, 2007 10:01 PM, Angel Java Lopez <***@gmail.com> wrote:


Hola gente!

Algunos comentarios, algo alejados pero relaciones a la pregunta original:

- Creo que el tema de que "vuelvan" DTOs hasta el dominio que son representacion
casi igual de los objetos del dominio, casi solo se da en los casos de ABM
(altas, bajas y modificaciones).
- Trato de imaginar un dominio, donde el NHibernate es apenas el encargado de la
persistencia, ortogonal al dominio, idealmente transparente.
- El dominio es un "bicho" al que le enviamos mensajes y comienza a trabajar. El
mensaje llega desde otro lado, quizas desde la presentacion. Caso tipico: en un
sistema de consorcios, le enviamos a calcular la liquidacion de un consorcio. No
le enviamos desde la presentacion al dominio un consorcio: apenas le enviamos
algun identificador, y un rango de fechas de gastos a liquidar (espero que se
entienda el ejemplo, fuera de Argentina)
- A presentacion van y vuelven mensajes, adecuados al paso(s) del caso de uso
que tengamos entre manos. Si los DTOs se deben adecuar a la forma de transporte
o exposicion (p.ej., tener un [DataContract] en WCF, o tener [Serializable] en
Remoting), es un tema tecnologico que a dominio, y su persistencia en
NHibernate, apenas le deberia importar. Si no hay tema de transporte remoto,
igual me gustaria pensar en mensajes, adecuados al caso de uso, y si envio un
objeto de dominio, tener todo el "awareness" de que estoy haciendo eso, por
alguna razon tactica o pereza.

A veces, veo muchas preguntas sobre el uso de NHibernate, pidiendole que haga
cosas que no son su responsabilidad (no digo que sea el caso de la pregunta de
abajo, que apunta a otra cosa, solo queria aprovechar este mensaje para enviar
esta opinion). Creo que puede pedirse algo asi, pero estar "aware", advertidos,
que no es la herramienta para dar DTOs, o para clonarlos o lo que sea. Si lo
usamos de esa manera, es por una razon tactica oportunista: simplificar lo que
estamos haciendo, escribir menos codigo (algo que cualquier usuario de AjGenesis
ni tiene que temer... ;-), y otras....

No se si aclare u oscureci.... ;-)

Nos leemos!

Angel "Java" Lopez
http://www.ajlopez.com/



----- Original Message -----
From: Gustavo Ringel <mailto:***@gmail.com>
To: nhibernate-***@googlegroups.com
Sent: Sunday, December 02, 2007 12:44 PM
Subject: [NHibernate-Hispano] consulta sobre buen diseño

Hi, tengo un lio que siempre que empiezo una nueva aplicacion, dudo como diseñar
correctamente y nunca llego a algo concreto.

Hoy en dia en mi aplicacion cree DTO's, que tienen la version de las business
entities como las ve el cliente. Si bien mi aplicacion no esta distribuida, los
servicios igual devuelven y reciben DTO's, la idea en su momento era por un lado
no mandar informacion a las vistas que no les interesa y ademas posibilidad de
escalar a WCF o Web Services o lo que fuera con facilidad.

Esto quiere decir que para business entity tengo que transformar la entidad en
DTO y viceversa.

Ahora estoy escribiendo una nueva aplicacion y nuevamente me veo obligado a
duplicar informacion cuando la aplicacion cliente y servidor por ahora son la
misma, y por razones de ambiente tampoco creo que trabaje WCF/Remoting o ninguna
alternativa...

Basicamente salvo que no tiene nada que hacer con la informacion extra, podria
leer un objeto nhibernate, clonarlo para desconectarme del proxy y devolver el
mismo tipo de objeto al cliente. Cuando el cliente me manda un objeto de vuelta
podria hacer Load del id y trabajar con el objeto NHibernate...

Claramente esta ultima opcion parece muy sucia a nivel del codigo. Ahora la
pregunta es que hacen ustedes...tambien si la session de nhibernate la manejan a
nivel de servicios como hacen para trabajar con transacciones
multiservicio...(TransactionScope?)


Gracias.

Gustavo.







--~--~---------~--~----~------------~-------~--~----~
Para escribir al Grupo, hágalo a esta dirección: NHibernate-***@googlegroups.com
Para más, visite: http://groups.google.com/group/NHibernate-Hispano
-~----------~----~----~----~------~----~------~--~---

[Omar del Valle Rodriguez]

Ja.. Mil gracias por permitirme escuchar esto.



Gustavo, no temas.. que a mí me pasaba lo mismo. Hasta hace poco moría
buscando por internet una herramienta que me permitiese crear DTOs a partir
de objetos de NH y después hacer la operación inversa. Te encuentras de
todo, hasta clases genéricas, Clones, Serializables, pero todos al final
tienen un gran problema, y es justamente lo que menciona Carlos, al final,
tenemos objetos por gusto y pasamos datos entre capas que ni son necesarias.



Hace poco comencé un proyecto, la conclusión que saqué de toda mi búsqueda
por internet fue precisamente la que acaba de exponer Carlos. Por eso doy
mil gracias por saber que no estaba en un error.



Salu2

Omar



De: NHibernate-***@googlegroups.com
[mailto:NHibernate-***@googlegroups.com] En nombre de Carlos Peix
Enviado el: Monday, December 03, 2007 11:27 PM
Para: NHibernate-***@googlegroups.com
Asunto: [NHibernate-Hispano] Re: [OT] Re: consulta sobre buen diseño



Hola Gustavo,



Nota: Creo que esto es util para todos pero tambien me parece que es un OT,
asi que lo marque en el asunto.



Te cuento como pienso yo estos casos.

Los DTOs los entiendo como objetos especificos para resolver las necesidades
de comunicacion en un caso determinado. Nunca comienzo creando un DTO por
cada objeto de dominio. Eso me ha llevado a tener objetos que nunca uso y a
que me falten objetos o que no sea eficiente con los DTOs.



Entonces, en el caso que planteaste crearia un DTO especial para la
"pantalla de edicion masiva de numeros de telefono". Este DTO tendria cuatro
propiedades: CUIT (clave tributaria), Descroipcion del proveedor, tenefono
actual, telefono nuevo (inicialmente igual al actual).



Devolveria una coleccion de estos objetos desde la consulta y el cliente
editaria esos datos. Luego el cliente me envia al webservice solo los
objetos que fueron editados y el servicio haria los cambios sobre el modelo.
Si esta coleccion de telefonos editados la colocas en un objeto especial
llamado (por ejemplo) CambioDeTelefonosRequest tenes el mensaje que menciona
Angel. El servicio respondera con el correspondiente mensaje XXXX.Response y
listo.



Saludos



Carlos Peix




_____


From: NHibernate-***@googlegroups.com
[mailto:NHibernate-***@googlegroups.com] On Behalf Of Gustavo Ringel
Sent: Domingo, 02 de Diciembre de 2007 05:15 p.m.
To: NHibernate-***@googlegroups.com
Subject: [NHibernate-Hispano] Re: consulta sobre buen diseño

Hi Angel, basicamente respondes. Ahora una consulta respecto a eso...segun
tu opinion digamos que en el dominio yo tengo una entidad compleja, por
decir algo "Proveedor" identificada por un ID Int32.

Supongamos que tengo varios elementos en la base asociado al proveedor, pero
mando datos a una consulta en la que paso por todos los proveedores y solo
quiero actualizar el telefono si es necesario.

El servicio seria por ejemplo GetProveedores(Algun filtro) y
SetTelefono(DTOProveedor) donde DTOProveedor seria un ID + Telefono?



Es decir, vos le revelarias al cliente que utilizas el campo ID para
identificar cuando vuelve? ese es justamente el problema que yo no logro
solucionar elegantemente, si maniana quiero cambiar a GUID la identificacion
o el tipo de datos no es suficiente para la cantidad de datos manejados,
tengo que cambiar todos los DTO, mas los servicios...



Bue, capaz que me equivoco en la direccion de lo que vos decis.



Entiendo que no es una pregunta de NHibernate directo asi que pido
disculpas, pero la idea es justamente que NHibernate sea el manejador de la
persistencia y obtencion de datos del lado del servicio y estoy buscando la
forma de comunicarme con la capa de presentacion de manera adecuada...



Gustavo.

On Dec 2, 2007 10:01 PM, Angel Java Lopez <***@gmail.com> wrote:

Hola gente!



Algunos comentarios, algo alejados pero relaciones a la pregunta original:



- Creo que el tema de que "vuelvan" DTOs hasta el dominio que son
representacion casi igual de los objetos del dominio, casi solo se da en los
casos de ABM (altas, bajas y modificaciones).

- Trato de imaginar un dominio, donde el NHibernate es apenas el encargado
de la persistencia, ortogonal al dominio, idealmente transparente.

- El dominio es un "bicho" al que le enviamos mensajes y comienza a
trabajar. El mensaje llega desde otro lado, quizas desde la presentacion.
Caso tipico: en un sistema de consorcios, le enviamos a calcular la
liquidacion de un consorcio. No le enviamos desde la presentacion al dominio
un consorcio: apenas le enviamos algun identificador, y un rango de fechas
de gastos a liquidar (espero que se entienda el ejemplo, fuera de Argentina)


- A presentacion van y vuelven mensajes, adecuados al paso(s) del caso de
uso que tengamos entre manos. Si los DTOs se deben adecuar a la forma de
transporte o exposicion (p.ej., tener un [DataContract] en WCF, o tener
[Serializable] en Remoting), es un tema tecnologico que a dominio, y su
persistencia en NHibernate, apenas le deberia importar. Si no hay tema de
transporte remoto, igual me gustaria pensar en mensajes, adecuados al caso
de uso, y si envio un objeto de dominio, tener todo el "awareness" de que
estoy haciendo eso, por alguna razon tactica o pereza.



A veces, veo muchas preguntas sobre el uso de NHibernate, pidiendole que
haga cosas que no son su responsabilidad (no digo que sea el caso de la
pregunta de abajo, que apunta a otra cosa, solo queria aprovechar este
mensaje para enviar esta opinion). Creo que puede pedirse algo asi, pero
estar "aware", advertidos, que no es la herramienta para dar DTOs, o para
clonarlos o lo que sea. Si lo usamos de esa manera, es por una razon tactica
oportunista: simplificar lo que estamos haciendo, escribir menos codigo
(algo que cualquier usuario de AjGenesis ni tiene que temer... ;-), y
otras....



No se si aclare u oscureci.... ;-)



Nos leemos!



Angel "Java" Lopez

http://www.ajlopez.com/





----- Original Message -----

From: Gustavo Ringel <mailto:***@gmail.com>

To: nhibernate-***@googlegroups.com

Sent: Sunday, December 02, 2007 12:44 PM

Subject: [NHibernate-Hispano] consulta sobre buen diseño



Hi, tengo un lio que siempre que empiezo una nueva aplicacion, dudo como
diseñar correctamente y nunca llego a algo concreto.



Hoy en dia en mi aplicacion cree DTO's, que tienen la version de las
business entities como las ve el cliente. Si bien mi aplicacion no esta
distribuida, los servicios igual devuelven y reciben DTO's, la idea en su
momento era por un lado no mandar informacion a las vistas que no les
interesa y ademas posibilidad de escalar a WCF o Web Services o lo que fuera
con facilidad.



Esto quiere decir que para business entity tengo que transformar la entidad
en DTO y viceversa.



Ahora estoy escribiendo una nueva aplicacion y nuevamente me veo obligado a
duplicar informacion cuando la aplicacion cliente y servidor por ahora son
la misma, y por razones de ambiente tampoco creo que trabaje WCF/Remoting o
ninguna alternativa...



Basicamente salvo que no tiene nada que hacer con la informacion extra,
podria leer un objeto nhibernate, clonarlo para desconectarme del proxy y
devolver el mismo tipo de objeto al cliente. Cuando el cliente me manda un
objeto de vuelta podria hacer Load del id y trabajar con el objeto
NHibernate...



Claramente esta ultima opcion parece muy sucia a nivel del codigo. Ahora la
pregunta es que hacen ustedes...tambien si la session de nhibernate la
manejan a nivel de servicios como hacen para trabajar con transacciones
multiservicio...(TransactionScope?)




Gracias.



Gustavo.


<BR


--~--~---------~--~----~------------~-------~--~----~
Para escribir al Grupo, hágalo a esta dirección: NHibernate-***@googlegroups.com
Para más, visite: http://groups.google.com/group/NHibernate-Hispano
-~----------~----~----~----~------~----~------~--~---

[Dario Quintana]

Hola a todos..

Me dió la impresión que decís que usar DTO en la aplicacion para el pasaje
de mensajes, es malo... yo no lo veo tan así. Quizás, sea la manera de
usarlos. Yo creo que son muy beneficiosos a la hora de mostrar datos en la
pantalla, y para el pasaje entre capas pero usandolos bien... es para
analizarlo.

Post by Omar del Valle Rodriguez
Ja.. Mil gracias por permitirme escuchar esto.
Gustavo, no temas.. que a mí me pasaba lo mismo. Hasta hace poco moría
buscando por internet una herramienta que me permitiese crear DTOs a partir
de objetos de NH y después hacer la operación inversa. Te encuentras de
todo, hasta clases genéricas, Clones, Serializables, pero todos al final
tienen un gran problema, y es justamente lo que menciona Carlos, al final,
tenemos objetos por gusto y pasamos datos entre capas que ni son necesarias.
Hace poco comencé un proyecto, la conclusión que saqué de toda mi búsqueda
por internet fue precisamente la que acaba de exponer Carlos. Por eso doy
mil gracias por saber que no estaba en un error.

[Omar del Valle Rodriguez]

Bueno..



Quizás esté en un error.. pero para mí un DTO.. es eso, un Data Transfer
Object. Un objeto que me sirve para transportar datos entre capas, y con 0
lógica sobre mi dominio. Un medio de transporte público ;)



Salu2

Omar



De: NHibernate-***@googlegroups.com
[mailto:NHibernate-***@googlegroups.com] En nombre de Dario Quintana
Enviado el: Friday, December 07, 2007 10:38 PM
Para: NHibernate-***@googlegroups.com
Asunto: [NHibernate-Hispano] Re: [OT] Re: consulta sobre buen diseño



Hola a todos..

Me dió la impresión que decís que usar DTO en la aplicacion para el pasaje
de mensajes, es malo... yo no lo veo tan así. Quizás, sea la manera de
usarlos. Yo creo que son muy beneficiosos a la hora de mostrar datos en la
pantalla, y para el pasaje entre capas pero usandolos bien... es para
analizarlo.




On Dec 7, 2007 5:53 PM, Omar del Valle Rodriguez <***@yahoo.com.mx>
wrote:

Ja.. Mil gracias por permitirme escuchar esto.



Gustavo, no temas.. que a mí me pasaba lo mismo. Hasta hace poco moría
buscando por internet una herramienta que me permitiese crear DTOs a partir
de objetos de NH y después hacer la operación inversa. Te encuentras de
todo, hasta clases genéricas, Clones, Serializables, pero todos al final
tienen un gran problema, y es justamente lo que menciona Carlos, al final,
tenemos objetos por gusto y pasamos datos entre capas que ni son necesarias.



Hace poco comencé un proyecto, la conclusión que saqué de toda mi búsqueda
por internet fue precisamente la que acaba de exponer Carlos. Por eso doy
mil gracias por saber que no estaba en un error.

[Dario Quintana]

Hola,

Yo nunca dije que el DTO fuera otra cosa, pero hablabas de desventajas o
problemas que exponía Carlos y como que se dió a entender el "lado oscuro de
los DTO". Donde en realidad yo entendí que si los usás mal, vas a tener esos
problemas, no siempre.

Post by Omar del Valle Rodriguez
Bueno..
Quizás esté en un error.. pero para mí un DTO.. es eso, un Data Transfer
Object. Un objeto que me sirve para transportar datos entre capas, y con 0
lógica sobre mi dominio. Un medio de transporte público ;)

[Carlos Peix]

Hola Dario,

Creo que Omar no dice que no hay que usar DTOs, es justamente lo contrario. Lo
que el dice es que encontro con la practica (cosa que tambien me paso a mi) que
no es muy practico generar los DTOs automaticamente a partir de tu modelo.

En resumen, los DTOs son muy buenos, lo que a mi no me ha dado resultado es
generarlos en espejo con el modelo, a mi me resulta mas practico escribirlo
especialmente para cada necesidad de comunicacion.

Fijate en mi post de hace algunos dias, ahi di un ejemplo.

Abrazo

Carlos Peix


_____

From: NHibernate-***@googlegroups.com
[mailto:NHibernate-***@googlegroups.com] On Behalf Of Dario Quintana
Sent: Viernes, 07 de Diciembre de 2007 06:38 p.m.
To: NHibernate-***@googlegroups.com
Subject: [NHibernate-Hispano] Re: [OT] Re: consulta sobre buen diseño


Hola a todos..

Me dió la impresión que decís que usar DTO en la aplicacion para el pasaje de
mensajes, es malo... yo no lo veo tan así. Quizás, sea la manera de usarlos. Yo
creo que son muy beneficiosos a la hora de mostrar datos en la pantalla, y para
el pasaje entre capas pero usandolos bien... es para analizarlo.




On Dec 7, 2007 5:53 PM, Omar del Valle Rodriguez <***@yahoo.com.mx> wrote:


Ja.. Mil gracias por permitirme escuchar esto.



Gustavo, no temas.. que a mí me pasaba lo mismo. Hasta hace poco moría buscando
por internet una herramienta que me permitiese crear DTOs a partir de objetos de
NH y después hacer la operación inversa. Te encuentras de todo, hasta clases
genéricas, Clones, Serializables, pero todos al final tienen un gran problema, y
es justamente lo que menciona Carlos, al final, tenemos objetos por gusto y
pasamos datos entre capas que ni son necesarias.



Hace poco comencé un proyecto, la conclusión que saqué de toda mi búsqueda por
internet fue precisamente la que acaba de exponer Carlos. Por eso doy mil
gracias por saber que no estaba en un error.
--
Dario Quintana
http://darioquintana.com.ar/blogging <http://darioquintana.com.ar/blogging>




--~--~---------~--~----~------------~-------~--~----~
Para escribir al Grupo, hágalo a esta dirección: NHibernate-***@googlegroups.com
Para más, visite: http://groups.google.com/group/NHibernate-Hispano
-~----------~----~----~----~------~----~------~--~---

[Omar del Valle Rodriguez]

Exactamente.. ;) has expresado a lo mejor, de forma más clara, lo que quise
decir. De seguro ahora Dario lo entiende.



De paso, les digo que he logrado acoplar a mi proyecto los Rhino.Commons de
Ayende, realmente impresionante. Me llevó a leer un poco sobre el Windsor de
Castle, otro de los grandes aportes de este grupo.



Les dejo un link, para que vean un diagrama de secuencia de cómo
Rhino.Commos maneja la Session de NH, incluso en casos de Long Conversation,
que no es más que cuando necesitamos que la Session sobreviva por algo más
que un Request.



http://ayende.com/Wiki/(S(wjt01c55iiqvfq55kqbmoj45))/Default.aspx?Page=HttpM
odules



Salu2

Omar



De: NHibernate-***@googlegroups.com
[mailto:NHibernate-***@googlegroups.com] En nombre de Carlos Peix
Enviado el: Saturday, December 08, 2007 11:49 AM
Para: NHibernate-***@googlegroups.com
Asunto: [NHibernate-Hispano] Re: [OT] Re: consulta sobre buen diseño



Hola Dario,



Creo que Omar no dice que no hay que usar DTOs, es justamente lo contrario.
Lo que el dice es que encontro con la practica (cosa que tambien me paso a
mi) que no es muy practico generar los DTOs automaticamente a partir de tu
modelo.



En resumen, los DTOs son muy buenos, lo que a mi no me ha dado resultado es
generarlos en espejo con el modelo, a mi me resulta mas practico escribirlo
especialmente para cada necesidad de comunicacion.



Fijate en mi post de hace algunos dias, ahi di un ejemplo.



Abrazo



Carlos Peix




_____


From: NHibernate-***@googlegroups.com
[mailto:NHibernate-***@googlegroups.com] On Behalf Of Dario Quintana
Sent: Viernes, 07 de Diciembre de 2007 06:38 p.m.
To: NHibernate-***@googlegroups.com
Subject: [NHibernate-Hispano] Re: [OT] Re: consulta sobre buen diseño

Hola a todos..

Me dió la impresión que decís que usar DTO en la aplicacion para el pasaje
de mensajes, es malo... yo no lo veo tan así. Quizás, sea la manera de
usarlos. Yo creo que son muy beneficiosos a la hora de mostrar datos en la
pantalla, y para el pasaje entre capas pero usandolos bien... es para
analizarlo.




On Dec 7, 2007 5:53 PM, Omar del Valle Rodriguez <***@yahoo.com.mx>
wrote:

Ja.. Mil gracias por permitirme escuchar esto.



Gustavo, no temas.. que a mí me pasaba lo mismo. Hasta hace poco moría
buscando por internet una herramienta que me permitiese crear DTOs a partir
de objetos de NH y después hacer la operación inversa. Te encuentras de
todo, hasta clases genéricas, Clones, Serializables, pero todos al final
tienen un gran problema, y es justamente lo que menciona Carlos, al final,
tenemos objetos por gusto y pasamos datos entre capas que ni son necesarias.



Hace poco comencé un proyecto, la conclusión que saqué de toda mi búsqueda
por internet fue precisamente la que acaba de exponer Carlos. Por eso doy
mil gracias por saber que no estaba en un error.

[Fabio Maulo]

Post by Omar del Valle Rodriguez
Les dejo un link, para que vean un diagrama de secuencia de cómo
Rhino.Commos maneja la Session de NH, incluso en casos de Long Conversation,
que no es más que cuando necesitamos que la Session sobreviva por algo más
que un Request.

Tendré que ver que hay allí.

Personalmente prefiero el pattern Session-per-Conversation.
Lo tengo que extender un poco... por eso todavía no está publicado...
necesito tiempo para probarlo.

Bye.
Fabio Maulo

--~--~---------~--~----~------------~-------~--~----~
Para escribir al Grupo, hágalo a esta dirección: NHibernate-***@googlegroups.com
Para más, visite: http://groups.google.com/group/NHibernate-Hispano
-~----------~----~----~----~------~----~------~--~---

[Omar del Valle Rodriguez]

Jajaja.. te he estado provocando para que dieras tu opinión.. al fin!!!. :)

Cuando exista algo de lo que hablas publicado, no dejes de informarlo. Es un
tema que me interesa mucho. Me imagino que los cambios en NH no te den
tiempo para más, pero igual, sin que se vea como una asignación de tareas ;)
nos avisas en cuanto tengas algo.

Salu2
Omar

-----Mensaje original-----
De: NHibernate-***@googlegroups.com
[mailto:NHibernate-***@googlegroups.com] En nombre de Fabio Maulo
Enviado el: Saturday, December 08, 2007 3:31 PM
Para: NHibernate-***@googlegroups.com
Asunto: [NHibernate-Hispano] Re: [OT] Re: consulta sobre buen diseño

Post by Omar del Valle Rodriguez
Les dejo un link, para que vean un diagrama de secuencia de cómo
Rhino.Commos maneja la Session de NH, incluso en casos de Long

Conversation,

Post by Omar del Valle Rodriguez
que no es más que cuando necesitamos que la Session sobreviva por algo más
que un Request.

Tendré que ver que hay allí.

Personalmente prefiero el pattern Session-per-Conversation.
Lo tengo que extender un poco... por eso todavía no está publicado...
necesito tiempo para probarlo.



__________________________________________________
Correo Yahoo!
Espacio para todos tus mensajes, antivirus y antispam ¡gratis!
Regístrate ya - http://correo.yahoo.com.mx/


--~--~---------~--~----~------------~-------~--~----~
Para escribir al Grupo, hágalo a esta dirección: NHibernate-***@googlegroups.com
Para más, visite: http://groups.google.com/group/NHibernate-Hispano
-~----------~----~----~----~------~----~------~--~---

[Gonzalo Brusella]

Hola Gustavo:

Que lindo tema para hablar!!!

Vamos por partes, y desglosamos el problema.

NH, de lo que se hace cargo es de la persistencia, idealmente de objetos de
Dominio. Eso es totalmente transparente para vos (o debería serlo en esta
instancia).

Te voy a dar un ejemplo de arquitectura orientada a servicios un poco
llevada al extremo, como para hacerte una idea:

Supongamos el caso de un videoclub, donde tenes las siguientes entidades:

- Actor
- Director
- Película
- Socio
- IOperacion (esta es para contener las cosas que ventas, rentas y
reservas tengan en común, ej: Socio y como es una interface, no se persiste
directamente)
- Venta (Implementa IOperacion y es *persistible*)
- Renta (Implementa IOperacion y es *persistible*)
- Reserva (Implementa IOperacion y es *persistible*)


Bien. Asumamos que vamos a tener 2 front-ends distintos: uno Web, que es
para que el socio sepa que tiene el videoclub disponible y haga una reserva
y uno de desktop que es para el videoclub per se.

La idea es tener estos 2 FE's "flotando" arriba de una capa de Servicios.

Vamos a analizar un caso en el FE Web:

El Socio puede ver el listado de peliculas. Para esto tenés un DTO con los
datos que aparecen en el listado (Nombre, Año, Breve sinopsis, categoría,
duración, etc) + el ID de película. Esto se popula en base a lo que le
pedís a un servicio a tal efecto (Web Service, Remoting, WCF, etc) que te
devuelve una lista de objetos.

Cuando el usuario quiere ver mas sobre una determinada película, lo que
hacés es pedirle a otro servicio (a este le pasás el ID de película) que te
mande una "versión ampliada" del objeto de dominio, esto es otro DTO
(probablemente compuesto con datos de varios objetos de dominio)

FE Windows:

Salvo en los casos en los que necesites dar de alta o editar, nunca usas un
objeto de dominio completo en tu capa de servicios. Para todo usas DTO's
específicos.


¿ te ayuda ?
--
Gonzalo A. Brusella
***@brusella.com.ar
http://www.brusella.com.ar

-- Arduum sane munus

--~--~---------~--~----~------------~-------~--~----~
Para escribir al Grupo, hágalo a esta dirección: NHibernate-***@googlegroups.com
Para más, visite: http://groups.google.com/group/NHibernate-Hispano
-~----------~----~----~----~------~----~------~--~---

[Gustavo Ringel]

Hi Gonzalo...no se que paso, pero a partir de un cierto momento perdi los
mensajes del thread y recien vi el tuyo despues de varios dias...

La idea ayuda, y entiendo, tengo algunos problemas con el tema de usar un
identificador en un servicio, porque si luego por alguna razon cambio de
identificador se generan problemas...pero he visto que muchas soluciones con
DTO's las hacen asi...

No quiero extenderme mucho mas ya que en definitiva esta es una lista de
NHibernate...

Gracias.

Gustavo.

Post by Gonzalo Brusella
Que lindo tema para hablar!!!
Vamos por partes, y desglosamos el problema.
NH, de lo que se hace cargo es de la persistencia, idealmente de objetos
de Dominio. Eso es totalmente transparente para vos (o debería serlo en esta
instancia).
Te voy a dar un ejemplo de arquitectura orientada a servicios un poco
- Actor
- Director
- Película
- Socio
- IOperacion (esta es para contener las cosas que ventas, rentas y
reservas tengan en común, ej: Socio y como es una interface, no se persiste
directamente)
- Venta (Implementa IOperacion y es *persistible*)
- Renta (Implementa IOperacion y es *persistible*)
- Reserva (Implementa IOperacion y es *persistible*)
Bien. Asumamos que vamos a tener 2 front-ends distintos: uno Web, que es
para que el socio sepa que tiene el videoclub disponible y haga una reserva
y uno de desktop que es para el videoclub per se.
La idea es tener estos 2 FE's "flotando" arriba de una capa de Servicios.
El Socio puede ver el listado de peliculas. Para esto tenés un DTO con los
datos que aparecen en el listado (Nombre, Año, Breve sinopsis, categoría,
duración, etc) + el ID de película. Esto se popula en base a lo que le
pedís a un servicio a tal efecto (Web Service, Remoting, WCF, etc) que te
devuelve una lista de objetos.
Cuando el usuario quiere ver mas sobre una determinada película, lo que
hacés es pedirle a otro servicio (a este le pasás el ID de película) que te
mande una "versión ampliada" del objeto de dominio, esto es otro DTO
(probablemente compuesto con datos de varios objetos de dominio)
Salvo en los casos en los que necesites dar de alta o editar, nunca usas
un objeto de dominio completo en tu capa de servicios. Para todo usas DTO's
específicos.
¿ te ayuda ?
--
Gonzalo A. Brusella
http://www.brusella.com.ar
-- Arduum sane munus

--~--~---------~--~----~------------~-------~--~----~
Para escribir al Grupo, hágalo a esta dirección: NHibernate-***@googlegroups.com
Para más, visite: http://groups.google.com/group/NHibernate-Hispano
-~----------~----~----~----~------~----~------~--~---