Passive View

De manera similar a Supervising Presenter, el patrón Passive View deriva del patrón Model View Presenter (MVP).
Passive View tiene similitudes con Code Behind, ya que ambos intentan lograr una completa separación entre ActionScript y MXML.

Características del patrón

• El estado está en la vista
• La lógica está en el Presenter
• El Presenter observa la vista
• El Presenter actualiza la vista
• Presenter tiene constancia de la vista
• La vista no sabe que existe la entidad Presenter

La diferencia respecto a Supervising Presenter es el grado en que la lógica es extraída de la vista. En una aplicación con Supervising Presenter, las vistas están capacitadas para observar las clases de dominio o los value objects, para poder mostrar la información, pero las vistas en una aplicación Passive View, están controladas completamente a través de los objetos presenter.
El patrón Supervising Presenter se presta a los elementos de vista que tienen características de sincronización (por ejemplo los bindings en Flex), permitiendo a los controles de la vista sincronizarse directamente a través de las clases de dominio o los value objects. El patrón Passive View prohíbe este tipo de comportamiento en la vista, la sincronización entre vista y datos se controla con la clase presenter.

NOTAS SOBRE EL PATRÓN

Fácil de testear

Ya que se mueve todo el comportamiento fuera de la vista, el patrón Passive View es el que da más facilidad para hacer unit test. La clase presenter tiene una referencia a la vista, por lo que se necesitan mock objects.

Mejor separación
Nos puede ayudar a mejorar la separación en la aplicación. Mediante la composición en lugar de la herencia, Passive View logra un gran grado de desacoplamiento del Flex framework, comparándolo con el patrón Code Behind. Las clases Presenter no necesitan extender a los contenedores Flex.

Moviendo la lógica fuera de la vista, el patrón Passive View puede conseguir los mismos objetivos que el patrón Code Behind. La clase de vista resultante está libre de especificaciones de event handlers, bindings y bloques de script.

Se reduce el rol de MXML
Al no tener acceso a los bindings MXML y a las declaraciones de eventos, perdemos algunos de los aspectos más potentes de Flex.

Sobre el comportamiento declarativo
Hay comportamiento de presentación que puede declararse en los MXML: efectos, transiciones o validators, por ejemplo. No está claro si Passive View permite este tipo de lógica declarativa en la vista. Es más seguro dejar el comportamiento gráfico en la vista y controlar los cambios de estado desde el presenter, si es necesario. El comportamiento que no atañe a aspectos gráficos, como puede ser la validación, probablemente es mejor ponerlo en el presenter, ya que éste está más ligado al modelo de datos.

Aplicación de ejemplo
En el siguiente enlace hay un ejemplo se que comenta a continuación.

En este ejemplo vemos como las clases de tipo presenter son las que tienen constancia de la vista y la modifican. En concreto, si observamos la instanciación de la clase AlbumBrowserPresenter, se pasa al constructor la vista asociada, para que AlbumBrowserPresenter la modifique a su antojo en la lógica que implementa, en cambio, la vista no recibe ninguna información sobre AlbumBrowserPresenter.

Conclusiones sobre este patrón
Passive View va un paso más allá que Supervising Presenter, añadiendo condiciones adicionales sobre la autonomía de la vista. Pero lo que interesa de Passive View es como consigue lo mismo que Code Behind a partir de la composición en lugar de la herencia.