Cairngorm II: Value Objects

En el catálogo de patrones J2EE los llamaríamos TransferObjects.

Cuando empezamos el desarrollo de una aplicación, la toma de requerimientos puede llevarnos a tomar la decisión de consumir datos dinámicos a partir de XML’s, Web Services, DataObjects a través de RPC o cualquier otro sistema existente.

En una fase posterior del desarrollo puede darse el caso en que esto tenga que cambiar. Imaginemos el caso en que se decide utilizar SOAP como sistema de consumo de datos. Conforme la aplicación va creciendo y tiene que dimensionarse podemos experimentar problemas de rendimiento o una mala eficiencia del formato. Por ello deberíamos cambiar toda la capa de consumo de datos.


Dependiendo de cómo esté diseñada la arquitectura de nuestra aplicación este cambio podría tener un gran impacto y afectar no sólo al consumo de datos. Siguiendo con el ejemplo anterior si la lógica de nuestra aplicación utiliza objetos específicos arrastrados del modelo de datos, el cambio afectaría a dos capas. Esto es, si la lógica de nuestra aplicación trabaja sobre objetos XML puros en todas las capas sería realmente laborioso el cambiar la aplicación para que esta trabajara con objetos consumibles a través de RemoteObject.

Otro punto en contra de trabajar con objetos ceñidos a la capa de consumo es la limitación que podemos estar introduciendo a nuestro código. Sin ir más lejos, y aunque usemos e4x, un objeto parseado desde un XML no se puede castear a un objeto con identidad propia dentro de nuestra aplicación.

Si extrapolamos este problema a la parte servidora podríamos poner como ejemplo el cambio de motor de base de datos. Si inicialmente optamos por trabajar con una BBDD Access pero después por motivos de performance decidimos migrar a Oracle el cambio debería afectar sólo a la capa de consumo de datos y no a la lógica de mi aplicación. Si en mi aplicación he arrastrado a todas las capas objetos Recordset específicos de Access la migración será extensa ya que se perdería la compatibilidad.

Con el fin que un cambio en cualquiera de las capas (por profundo que sea) no afecte al resto de capas (ortogonalidad y baja cohesión de código) introducimos el concepto de Transfer Object o Value Object (en adelante VO’s). Este tipo de objetos suelen ser lightWeight y de una naturaleza muy simple. No tienen ningún tipo de business logic y son simples contenedores de datos estructurales (mapeo orientado a objetos).

Al tratarse de objetos transversales a todas las capas un cambio en la capa generadora de estos objetos no implica un cambio en las capas consumidoras y viceversa, consiguiendo así la ortogonalidad deseada.

Pongamos el ejemplo de una aplicación de lectura de noticias (sea el Pod de la home de madeinflex). La primera fase de toma de requerimientos nos lleva a adoptar la solución de consumir dichas noticias directamente desde xmls siguiendo el formato de RSS. En una iteración posterior se decide consumir noticias desde unos WebServices (por ejmplo mxna). El problema es que en el plano implementacional la estructura de datos que devuelven los SOAP no se parece en nada a la estructura de las RSS, aunque en el plano conceptual ambos modelos de datos son igualmente noticias.

La solución para evitar este tipo de problemas pasa por utilizar VO’s. Conceptualmente podemos ver una noticia como un objeto con tres campos: title, excerpt y link. En un plano implementacional podríamos definir este objeto como una clase: ItemVO

[ftf w=”500″ h=”200″]
package com.mif.cairngormTutorial1.vos
{
[Bindable]
public class ItemVO
{
public var title:String;
public var excerpt:String;
public var link:String;
}
}[/ftf]

Dependiendo de la fuente de datos este objeto se construirá de una forma u otra. En caso de consumir datos de un xml tendremos en alguna parte de nuestro código una función que sepa traducir desde un XML con una DTD concreta a nuestro objeto agnóstico al formato. Si consumimos los datos de un WebService, esta conversión se realizará siguiendo unas reglas distintas que si consumimos los datos a través de RemoteObject, etc.

Desde un punto de vista implementacional un VO puede estar constituido de propiedades simples como las del ejemplo anterior, pero también podría estar definido con getters y setters siguiendo más la forma de Java.

El que nuestra aplicación sólo use VO’s no sólo nos beneficia en grandes aplicaciones sujetas al cambio, sinó que además canaliza nuestro conocimiento entre distintas aplicaciones y fomenta la reutilización de otras clases (no vinculadas a un formato de datos concreto como XML).

Paralelamente a la capa de consumo de datos, podemos hacer que las propiedades de nuestros VOs sean [Bindables]. Lo cual implica que cualquier consumidor/suscriptor de una propiedad de nuestro VO será notificado si ésta cambia.

Esta peculiaridad, y potencia, permite relacionar el modelo de datos con la capa de presentación (View). Si bindeamos una propiedad de un VO a un widget visual que permita su visualización, en el momento en el que desde cualquier otro punto de nuestra aplicación se altere el valor de dicha propiedad, inmediatamente la representación visual de dichos datos se actualizará.

[ftf w=”500″ h=”500″]













[/ftf]

El hecho que ItemVO esté marcado como [Bindable] a nivel de clase implica que todas sus propiedades lo sean. De esta forma cuando se modifica el valor de las propiedades los TextInputs que tienen la propiedad text bindeada a alguna de las propiedades del VO, reflejan los cambios de inmediato.

Cairngorm trabaja de forma extensa con el concepto de VO, potenciando su uso. Como convenio se debería hacer que cada uno de nuestros VO’s implementa la inteface com.adobe.cairngorm.vo.ValueObject con el fin de potenciar el polimorfismo si en algun momento lo necesitáramos.

Xavi es un Technical Arquitect de Aplicaciones RIA basadas en la Plataforma Flash trabajando para Adobe en Londres. Especializado en aplicaciones colaborativas en tiempo real, e-learning y CMS (Content Management Systems) utiliza Flex, LCDS, BlazeDS, FMS y Java principalmente.

Sitio Web:http://www.code4net.com

18 Comentarios

  1. Israel Gaytan

    Excelente Xavi super bien explicado, me gustaria agregar tambien que el DTO (Value Object) esta super diseñado y optimizado para la transferencia de datos a traves de las capas , además de como dice Xavi optimiza de una manera importante las peticiones a traves de la red.

  2. Huge

    Muy interesante…

    Creo que va a ser buen momento que me lea otra vez la parte de patrones del libro de Colin Moock que la primera vez no me entere mucho…

    Saludos y enhorabuena por tus post.
    A la espera de los nuevos.. 🙂

  3. David

    Muy bien explicado Xavi, como siempre. Ya que me he puesto con Flex, que mejor manera, de hacerlo bien. Algo se me quedó de lo que me enseñó Xavi, xDDD.

  4. Pingback: MadeInFlex » Blog Archive » Introducción a Web Services con .NET III

  5. Pingback: MadeInFlex » Blog Archive » Caso de estudio: Flex store simplificado

  6. angel59

    Que tal, estoy aprendiendo un poco de flex, quiero implementar la vista de mis trabajos con flex ya que es mucho mas intuitiva que utilizar solo html y javascript, en este articulo noto que lo que llamas VO, no es otra cosa que un bean para java, o estoy equivocado?, bueno seguire leyendo las entrgas a fin de ponerme mas al dia.

  7. Ramon

    Leyendo el articulo me surge una duda, entendiendo por ejemplo un VO:

    class CategoriaVO{
    public var ID;
    public var Nombre;
    }
    Seria correcto lo siguiente ?? es decir meter un Vo dentro de otro VO:
    class ItemVO{
    public var ID;
    public var Nombre;
    public var CategoriaVO;
    }

    Gracias

  8. Xavi Beumala

    Hola Ramón,

    Sí el anidamiento de VO’s sería completamente lícito y de hecho con estructuras complejas de datos se convierte en imprescindible. Otra cosa muy común sería tener un VO con atributo o propiedad de tipo Array o ArrayCollection que conteniera a su vez otros VO’s

  9. Adrián

    Hola, enhorabuena por el artículo, estoy empezando a conocer esta nueva tecnología que me tiene fascinado.
    Yo tengo poca experiencia laboral y la que tengo ha sido prácticamente basada en php. Bueno lo que me interesaría saber es si es posible y fácil combinar distintos frameworks. Por ejemplo y volviendo al php, me gustaría utilizar cakephp para la parte del servidor y combinarlo con una interfaz flex con framework cairgornm. Como agente de transporte sólo conozco weborb para php y creo (personalmente) que no está muy maduro aún, conoceis otros mejores?
    Gracias y saludos

  10. JuanchoSL

    Hola a todos estoy empezando a conocer esta nueva tecnología que me tiene fascinado. Ahora mi duda ❓ Siguiendo el ejemplo del comentario de Ramon sobre el anidamiento de los VO`s como enlazariamos por ejemplo en un dataGrid una propiedad de CategoriaVO (suponiendo q esta contiene una propiedad nombreCategoria). Desde ya muchas gracias.

  11. Alex

    hola a todos, esta muy bueno el articulo … con lo que dijo ramón en la anidación de VO’s, existe algún patrón que explique un poco más ??, que pueda unir a value object

    desde ya gracias…

  12. Gabriel

    Muy buen post, sabes donde puedo encontrar mas información sobre la ejecución de Web Services que utilicen DTO´s tanto de entrada como de salida desde Flex?. Quiero migrar una GUI desarrollada en ASPX a Flex. Pero esta ejecuta WS que estan todos desarrollados bajo un “standar” de DTO (Request y Response) Gracias

  13. pepe

    Hola, estoy haciendo una aplicacion y queria saber si para recoger los datos obtenidos de la bd deberia hacer un vo o simplemente hacer un bean.
    Un saludo.

Deja un comentario

Tu dirección de correo electrónico no será publicada. Los campos obligatorios están marcados con *

Acerca de Made In Flex

Made In Flex es una comunidad de desarrolladores de Apache Flex creada en 2006.

Apache Flex, anteriormente conocido como Adobe Flex, es un SDK (kit de desarrollo de software) para crear aplicaciones enriquecidas - multiplataforma basadas en Adobe Flash donado por Adobe a la fundación Apache in 2011 y promocionado a proyecto de primer nivel en Diciembre de 2012.

Actualmente estamos cambiando muchos aspectos del sitio web para ofrecer un sitio útil para toda la comunidad que tenga en cuenta las necesidades actuales.

Últimas Fotos

Instalador de Apache Flex

Entrar o Registrase