En el post anterior vimos que los commands son stateless y que son el núcleo funcional de las distintas partes de una aplicación. Poniendo el ejemplo de “cargar los datos de un usuario dado�? veamos cómo abordaríamos su implementación a alto nivel.
El command tendría que utilizar un service que le permitiera establecer una conexión con la parte servidora. Si por ejemplo tenemos una página .aspx, .jsp, .php, un servlet, etc que pasándole como parámetro un id nos devuelve en formato xml la información de un usuario. Tendríamos que declarar este service en nuestro serviceLocator.
Posteriormente podríamos invocar la petición desde cualquier command. Veamos un pequeño ejemplo:
La implementación podría quedar así y sería totalmente válida. Pero fijémonos que en ningún lado hemos hablado de lo que se hará una vez se obtenga la respuesta de la invocación del servicio. Seguramente un servicio o un método de este pueda invocarse de distintas formas (comando) y cada una de ellas tratará los resultados de una forma distinta.
Vemos entonces que la invocación de los servicios tiene que parametrizar siempre la forma de tratar la respuesta. Para solventar esto se introduce el concepto de Responder. A nivel implementacional no es más una interface que define un método result y otro fault que se ejecutarán cuando el resultado de la invocación del service sean satisfactoria o no.
Paralelamente a este problema en un desarrollo distribuido cliente/servidor normalmente trabajan distintos perfiles: especialistas cliente y especialistas servidor. Es muy normal que las fases de desarrollo cliente / servidor se paralelicen, de tal forma que el desarrollo de la parte cliente pueda continuar sin necesidad de que la parte servidora esté completa.
Esta es una de las justificaciones del patrón Business Delegate, el cual permite crear una capa temporal que gestione las respuestas y que en determinadas situaciones pueda simular una parte del aplicativo aún por desarrollar devolviendo Mock Objects (Objetos generados de forma hard coded que emulan una posible respuesta).
Resumiendo, los Business Delegate nos permiten gestionar la forma en cómo tratar las respuestas recibidas desde el servidor así como el simularlas agilizando el desarrollo.
Tal como comentábamos en el punto uno (Value Objects), en un aplicativo se debería tratar siempre con ValueObjects transversales a la tecnología utilizada en las distintas capas, es conveniente tratar con objetos que no comprometan el futuro de nuestras aplicaciones. Tal como comentábamos aunque nuestro aplicativo consuma datos dinámicos en formato XML, SOAP, etc. es muy interesante convertirlos a VO’s. Los delegates al tener el control sobre las invocaciones al servidor y a sus respuestas, es el sitio ideal donde hacer el tratamiento de la información recibida y por ejemplo parsear de XML a VO’s.
Los delegates también son la parte que aislan la aplicacición de la tecnología utilizada en el servidor. Si tenemos un aplicativo que consume datos en formato XML y queremos pasar a utilizar FDS o cualquier otra solución basada en AMF sólo tendríamos que cambiar el delegate.
Veamos un ejemplo de un delegate:
Un uso muy potente que podríamos dar a los delegates consistiría en definirlos implementando una interface. Si tenemos varias implementaciones, estas serían intercambiables. Si en los commands referenciármos al delegate a través de su interface y no a través de su implementación concreta obtendríamos un sistema capaz de consumir los mismos datos pero a partir de fuentes distintas. Esta solución se podría usar por ejemplo en sistemas de alto tráfico donde en determinados momentos convendría consumir datos de forma dinámica (FDS, xml dinámico a partir de .phh, .asp, .jsp, servlets, etc) o a partir de ficheros estáticos en formato xml previamente generados en el servidor.
Fte: http://www.madeinflex.com/2007/01/23/cairngorm-vii-business-delegate/
No hay comentarios:
Publicar un comentario