Aprendre plegats
dimarts, d’abril 26, 2005
 
ES2(40) Patró Data Transfer Object (DTO)
El tercer, i darrer, patró que us demanem d'aprendre autònomament és l'anomenat Data Transfer Object (DTO). També s'anomena Transfer Object o Value Object. Hi ha diversos llocs on podreu trobar informació d'aquest patró. Per exemple:
Si voleu, podeu usar aquesta entrada del blog per compartir el vostre estudi del tema. En particular, podeu mirar de respondre aquesta pregunta:

Expliqueu els trets principals del Patró de Disseny Data Transfer Object (DTO): en quin context s’aplica, quin problema vol resoldre i en què consisteix la solució que proposa. Ajudeu-vos d’un exemple il·lustratiu.

Comments:
Context/Problema: Quant estàs dissenyant una aplicació distribuïda, i per satisfer la petició d' un client, et trobes que tu mateix estàs fent crides a una interfície remota, que fa incrementar el temps de resposta mes enllà de nivells acceptables.

Objectiu DTO: Encapsular i passar atributs de dades d' un objecte de negoci a la capa de presentació. Redueix el tràfic remot de la xarxa i ajuda a mantenir una separació neta entre el servidor i EJBs.

Solució Problema: Crear un DTO tal que guardi totes les dades que son requerides per una crida remota. Modificar la signatura del mètode remot per tal que accepti el DTO com a únic paràmetre i per que retorni un únic paràmetre DTO al client. Després de la crida, l' aplicació rep el DTO i el guarda com un objecte local, l' aplicació pot fer una sèrie de crides individuals al DTO sense incurrir en les crides remotes.
 
·Context:

Aquest patró es pot utilitzar quan estas dissenyant una aplicació distribuïda,i per satisfer una petició d'un sol client et trobes que el sistema fa múltiples crides a una interfície remota, la qual cosa incrementa el temps de resposta més enllà del límit acceptable

·Problema:

Com podem preservar la semàntica simple d'una interfície de crida d'un procediment sense estar subjectes a aspectes de latència inherents en les comunicacions remotes ?

·Solució:

Crear un nou objecte DTO (Data Transfer Object) que contingui totes les dades necessàries per la crida remota. Modificar la signatura del mètode remot per acceptar el DTO com a únic paràmetre i per retornar només un únic objecte DTO al client. Després que l'aplicació que ha cridat el procediment rep el DTO i l'emmagatzema com un objecte local, l'aplicació pot fer una sèrie de crides individuas a procediments al DTO sense augmentar d'aquesta manera el nombre de crides a procediments remots, i per tant, sense augmentar el temps d'espera.

Per més informació:
http://msdn.microsoft.com/library/default.asp?url=/library/en-us/dnpatterns/html/DesDTO.asp

Exemple d'aplicació:
http://msdn.microsoft.com/library/default.asp?url=/library/en-us/dnpatterns/html/ImpDTODataSet.asp
 
Tindria sentit usar el patró DTO i el patró representant (proxy) alhora? Potser podríem mantenir informació de l'objecte DTO dins del representant per a tenir més assegurada la baixa latència entre comunicacions remotes (per exemple, si enviem o rebem més d'una vega el mateix DTO). O potser així emmagatxemaríem massa informació irrellevant i no valdria la pena... Alguna idea?
 
Publica un comentari a l'entrada

<< Home

Powered by Blogger