View Helper

La idea del patrón View Helper es la de extraer la lógica de las vistas en clases. Empecemos a diseccionar dicho patrón

Características del patrón

• El estado está principalmente en la vista
• La lógica está en el view helper
• La vista tiene conocimiento del view helper
• El view helper tiene conocimiento de la vista

NOTAS SOBRE EL PATRÓN

Mediación
Este patrón tiene su origen en el desarrollo de aplicaciones RIA usando Flash. Se creó para actuar como mediador entre la aplicación y las vistas, que eran construidas a partir de la herencia de movie clips. Para que los movie clips pudieran encontrar a los otros y colaborar directamente, necesitaban conocer la estructura de la vista. Para no duplicar este conocimiento en toda la jerarquía de vistas, éste se encapsulaba en una clase view helper. De esta manera, cuando la estructura de la vista cambia, sólo es necesario actualizar el view helper.

Este problema es menor en Flex debido a como se compone la jerarquía de vistas. El patrón mediador es sin duda relevante para aplicaciones Flex: tanto View Helper como Supervising Presenter lo utilizan para tratar la comunicación entre los componentes de la user interface.

Segregación del lenguaje
Otra justificación del patrón View Helper es la segregación de MXML y ActionScript. Para unos ésto es para mejorar la lectura del código, para otros sólo es para seguir un workflow de trabajo.

Desacoplamiento
Antes de los bindings de Flex y del concepto de Model Locator, era necesario actualizar directamente las vistas con los resultados de operaciones remotas. Para evitar el acoplamiento con las vistas, View Helper se usó como intermediario. El patrón View Locator se usó para permitir a los view helpers ser localizados por los commands.

Unit testing
Tal como se ha dicho con Supervising Presenter y Presentation Model, es importante tener en cuenta el testeo. Desde la perspectiva de view helper, la referencia hacia la vista causará las mismas dificultades en unit testing que las que presenta Supervising Presenter. Las dependencias pueden disminuir utilizando una interface que implementen las vistas y el que el view helper instancíe con una clase concreta de vista. Esto permitiría el testing de view helper con mock objects.

Librerías en lugar de clases
Las clases View Helper son más o menos como librerías ActionScript para sus correspondientes vistas. En muchos casos, estos View Helpers forman una estructura de colaboración o coexisten dentro de una jerarquía de clases más amplia, y no pueden ser descritos como una capa arquitectural. Cada una es un fichero que esconde la lógica de una vista en particular.

Los View helpers no se comunican
Si se mira la aplicación de ejemplo, se puede observar que no hay asociaciones directas entre los view helpers. Aunque la lógica se ha extraído de la vista en clases separadas, esta nueva clase debe colaborar con las otras clases. La falta de asociaciones entre los view helpers limita su potencial.
Una manera de evitar este problema es mover algunos setters de la lógica a la vista. Otra aproximación sería la de crear un sigleton que permitiera a los view helpers ser localizados por otros view helpers.

El view helper es un subordinado de la vista. Es difícil la localización de éste sin su vista asociada.

Aplicación de ejemplo
En este ejemplo se puede ver la funcionalidad de este patrón.

En el código se ve como los helpers reciben la vista a la que están relacionados, y también como la vista contiene a su helper. Esto muestra la relación bidireccional entre estas clases e implica un acoplamiento muy alto.

Cada clase helper es la que implementa la lógica necesaria para su vista. Se observa también como la clase helper, en ocasiones, modifica su vista asociada, la cual cosa puede llevar a confusión ya que los cambios en la vista se esperan que se hagan en ésta.

Conclusiones sobre este patrón
Parece no lograr los beneficios que aportan Supervising Presenter o Presentation Model y esto ha hecho que se vaya olvidando y perdiendo relevancia. No consigue la misma separación que Supervising Presenter: hay un acoplamiento bidireccional entre la vista y el helper y este último debe basarse en la vista para poder colaborar con otros view helpers.