Presentation Model

Este patrón se basa en la idea del patrón Model-View-Controller.
Un modelo de presentación es una abstracción de la vista, es decir, el model representa el comportamiento y estado de la vista. La vista representa una proyección o representación del modelo en la pantalla. Cuando hay un cambio en el presentation model, la vista se actualiza en la pantalla.

Podemos tener dos variantes: una en la que la vista observa el modelo, y otra en la que el modelo observa la vista. En Flex es más fácil que las vistas MXML observen a los modelos.

Características del patrón
• El estado está en la clase presentation model
• La lógica está en la clase presentation model
• La vista observa el modelo y se actualiza en acorde con éste
• La vista tiene constancia del presentation model
• El presentation model no conoce que existe la vista

La sincronización entre modelo y vista se suele hacer mediante el patrón observer, Flex lo consigue con los MXML bindings. Aunque la vista conoce su modelo, el modelo desconoce la vista; comparando con el patrón Supervising Presenter, éste lo aplica al contrario.
Además, con Presentation Model, el estado y lógica de la vista se sacan de ésta y se colocan en el modelo de presentación. Recordemos que Supervising Presenter mueve la lógica fuera de la vista y que Autonomous View hace que la lógica y el estado permanezcan en la vista.

NOTAS SOBRE EL PATRÓN

Testabilidad
Ya que en este patrón el modelo está completamente desacoplado de la vista, es mucho más fácil testear la lógica.
Esto pone el patrón Presentation Model por delante del Supervising Presenter, ya que este último tiene una referencia a la vista.

Mejor separación
Si cada presentation model representa una abstracción de una vista, todos ellos pueden componer el modelo de toda una aplicación. El comportamiento común de la presentación puede ser refactorizado en clases base y compartido por todo el modelo.

¿Cuánta lógica y estados deben extraerse?
Tantos como sea posible. Los datos de presentación no gráfica son candidatos para ser extraidos hacua el modelo.
La presentación tiene muchos componentes gráficos, como las animaciones o el drag-and-drop, y esto es mejor que esté en la vista. Codificar esta lógica en el model puede requerir mucho conocimiento de la pantalla, layouts o widgets que están siendo utilizados.

Cierta lógica es probable que se mantenga en la vista
La lógica que está directamente acoplada a la parte gráfica, debe permanecer en la vista. Supervising Presenter no tiene esta restricción, ya que esta clase tiene permitido el conocimiento de la vista.
La vista también debe ser “inteligente”, lo suficiente como para saber qué métodos debe llamar del modelo de presentación en respuesta a eventos de entrada.

Aplicación de ejemplo
Este ejemplo enseña el uso de Presentation Model.

A continuación os presento el diagrama de clases de este ejemplo:

Este ejemplo tiene dos clases de tipo Presentation Model, AlbumBrowser y AlbumForm. Estas clases contienen la lógica relacionada con la vista a la que están asociadas. A parte, también mantienen el estado de las vistas. Para poner un ejemplo, centrémonos con la clase AlbumBrowser: la lógica de la vista viene definida por funciones como changeSelectedAlbum, el estado se controla con los atributos, previousSelectedAlbum y saveWarning.

Además, este ejemplo es interesante porque hay una implementación del patrón Observer, patrón en el que se basa el concepto de Binding.

Conclusiones sobre este patrón
Tanto Supervising Presenter como Presentation Model permiten separar la jerarquía de clases. El primero usa la interfaz de usuario para almacenar el estado, este último coloca el estado en la misma clase que la lógica. Al ser desacoplado de la vista, el patrón Presentation Model ofrece un mejor testing y desacoplamiento de la vista.