Reflexiones sobre el patrón Presentation Model

En madeinflex, hace un tiempo resumimos los patrones de presentación mediante una serie de artículos. En este artículo nos centraremos en concreto en el patrón Presentation model. Entre otras cosas, hablaremos de como relacionarlo con las vistas y de la comunicación entre diferentes Presentation Models según la composición de la GUI.

Introducción

Personalmente creo que es un patrón muy útil que nos descarga la vista de lógica que no es propia de ésta, hace más claro el seguimiento de la traza del código y nos proporciona una flexibilidad interesante a la hora de testear aplicaciones, entre otras cosas.

Según Martin Fowler, un referente en el mundo del software, el patrón Presentation Model (PM) representa el estado y el comportamiento de la presentación, independientemente de la vista y los elementos visuales que la componen. También se conoce como Application Model.

Con PM ponemos el estado y comportamiento de la vista fuera de ésta, en una clase de modelo que será parte de la presentación. Presentation Model nos coordina la capa de dominio y nos provee de una interface para minimizar las responsabilidades en la vista. La vista consulta su estado y comportamiento sincronizándose con el PM. El patrón PM puede interactuar con distintos objetos de dominio, pero no nos confundamos, PM no es un facade para que la vista consulte los objetos de dominio.

Aunque diferentes vistas pueden consultar un mismo PM, lo correcto es que cada vista requiera sólo un PM. En el caso de la composición, un PM puede contener una o varias instancias a otros PMs, pero cada subvista se relaciona sólo con un PM o al menos eso es lo ideal.

Ahora que hemos recordado y aclarado el concepto de PM, es interesante ver las diferentes maneras de aplicar este patrón a Flex. Seguiré la explicación que hace Tom Sugden de Adobe Consulting en uno de sus artículos, donde nos muestra las posibles maneras de usar este patrón según las relaciones entre las distintas vistas de nuestra aplicación. Podemos decir que a grandes rasgos hay dos maneras de aplicar PM: jerárquicamente o adaptada a los componentes.

Aplicaciones del patrón Presentation Model

Aproximación jerárquica

Con esta aproximación, tenemos una jerarquía de PMs, que refleja la jerarquía de los componentes visuales, como podemos ver en la siguiente figura:

Como vemos, cada vista tiene su correspondiente PM. La vista principal contiene sus subvistas y de la misma manera el PM principal tiene referencia a los otros PM. Con esta aproximación, el PM principal se suele instanciar en la vista principal. Éste puede ser un singleton si necesitamos que otras partes de la aplicación, como por ejemplo los commands, accedan a él. Los PMs de las subvistas se pasan a éstas de la siguiente forma:

Si usamos una jerarquía de PMs, la coordinación entre éstos debe ser mediante llamadas a métodos, compartiendo los datos que sean necesarios y/o lanzando eventos a través de la jerarquía. Por ejemplo, si en la vista 2 tenemos un DataGrid y seleccionamos un ítem de este componente, la propiedad selectedItem del PM de la vista 2 debe ser actualizada y avisar al PM principal de este cambio mediante un evento. Entonces el PM principal hará lo que tenga que hacer en función de esta acción.

Aproximación adaptada a los componentes

Mediante esta forma de usar los PMs, tenemos una única jerarquía, que es la de las vistas. Cada vista tiene su correspondiente PM, pero éstos son independientes entre sí como podemos ver en la siguiente figura:

De esta manera, los PMs suelen ser inyectados a las vistas usando frameworks IoC como Parsley. Un ejemplo de código:

No hace falta pasar el modelo a las subvistas, ya que cada una de éstas se preocupa de pedirlo.
Aunque los PMs se mantienen independientes entre sí, en esta aproximación es necesaria una coordinación. Se puede conseguir mediante un framework IoC, ya sea Parsley, Swiz o Spring ActionScript. Hay diferentes formas de conseguir esta comunicación:

• Mediante Messaging: enviar mensajes directamente entre los modelos usando algún mecanismo del framework. Coincido con Tom Sugden en usar Parsley 2, ya que incluye un framework de mensajería con bajo acoplamiento. Por otro lado, Swiz tiene un sistema de notación a través de tags Mediate para capturar los eventos. En cambio Cairngorm tiene un singleton para lanzar eventos de forma centralizada.
• Interfaces de Dominio: consiste en inyectar en diferentes PMs modelos de dominio compartidos. En este caso la coordinación se lleva a cabo llamando desde los PMs métodos de las interfaces de estos dominios que hayamos definido y escuchando los eventos que las llamadas puedan lanzar. Todos los frameworks IoC soportan esta característica.
• Controller/Presenter: usar clases separadas, conocidas como controllers o presenters, para coordinar los distintos PMs. Estas clases se suelen inyectar en determinados PMs mediante algún framework IoC. Los controllers están a la escucha de los eventos e invocan métodos en los PMs.

Cada aproximación que hemos abordado obtiene un resultado similar en cuanto a desacoplamiento entre los componentes. En el siguiente punto veremos una comparación de los PMs en cuanto a las consecuencias cuando hay cambios.

Respuesta al cambio

Durante el desarrollo de una aplicación siempre hay cambios debidos a la demanda de los clientes o de los usuarios, entre otras causas. Es importantísimo pensar el código antes de implementar para que los cambios no supongan un desastre en un proyecto, es decir, programar pensando en minimizar el coste del cambio que se puede dar. Esto, en parte se consigue construyendo por una parte los componentes que formarán la aplicación y por otro lado, intentar separar la lógica para que ésta, igual que los componentes, puedan ser reusados si es necesario.
Pongamos el siguiente escenario: un componente visual tiene que moverse de una parte de la GUI a otra. Si nos centramos en el primer diagrama, el de la relación jerárquica, este cambio en la GUI implicará cambios en cuatro clases, las que están resaltadas en color naranja:

Analicemos estos cambios:
La vista 3 ha sido movida de la vista 1 a la vista 2. De manera semejante se han tenido que adaptar los cambios entre los PMs: el PM 3 estaba contenido dentro del PM 1 y ahora es parte del PM 2. Toda la lógica que PM 1 ejecutaba directamente sobre PM 3, ahora deberá pasar antes por el PM 2 o mover esta lógica al PM 2.

Mirando en profundidad la aproximación adaptada a componentes ( la segunda imagen de este artículo), podemos observer que tiene una adaptación más fácil al cambio. Sólo es necesario mover la vista 3 de la vista 1 que colgaba a la vista 2.
Debido a que la lógica de los componentes está controlada con la relación Vista->PM y la coordinación entre PMs se hace externamente a través de mensajes, interfaces de dominio o controller/presenters, no nos supondrá cambios tan críticos. Si tenemos que testear nuestra aplicación, los unit test de los PMs permanecerán intactos, en cambio, en la aproximación por jerarquía deberíamos refactorizarlos. Mostramos en la siguiente imagen los cambios sobre una implementación adaptada a componentes:

Conclusión

EL patrón Presentation Model es el más útil para desarrollar aplicaciones Flex que deban ser testeadas. Esto se produce porque movemos el estado y la lógica a los PMs y así podemos testear aisladamente los PMs. Es fácil entender que es mucho más fácil testear aplicaciones que usen PMs en lugar de poner la lógica en bloques script directamente en las vistas.
Por otra parte, sabiendo que durante el proceso de desarrollo de una aplicación hay cambios constantemente por nuevos requisitos que nos imponen; vemos que es recomendable usar la aproximación adaptada a componentes, que nos permitirá adaptarnos a esos cambios de una forma más fácil que la aproximación jerárquica.