Code Behind vs MXML Script Block vs View Helper. Conclusiones de los patrones de presentación

Sobre la pregunta de donde colocar el código relacionado a un fichero MXML, seguramente, las tres soluciones más utilizadas en el mundo Flex son code behind, script blocks o view helper.

Un script block es la parte de código ActionScript que se coloca entre los tags .

Ya hemos visto la definición de view helper, pero para resumir podemos decir que es una clase ActionScript a la que un fichero MXML puede llamar y escuchar directamente. Normalmente contiene código relacionado con el fichero MXML y funcionalidades que si no estuviera esta clase irían en el fichero MXML en script blocks.

Code behind también lo hemos visto con anterioridad, pero para dar un resumen de este patrón, podemos decir que es una manera sencilla y rápida de organizar la funcionalidad. Si movemos el código de un script block a una clase code behind, estamos cambiando la localización de éste y ensuciando la sintaxis para acceder a este código.

Es adecuado poner el código en una clase ActionScript externa, cuando este código no contiene referencias a vistas.
Lo más adecuado es extraer el código a clases que tengan reglas OOP, así serán fáciles de testear y fáciles de acceder. Si cargamos las vistas de funcionalidades, estaremos sobrecargando estas vistas con responsabilidades que no le atañen, y seguramente duplicando código.

La meta es no cargar las vistas con código que no le pertenece o código excesivo.

 
CONCLUSIONES

Está comprobado que Flex es capaz de soportar la implementación de cualquiera de los seis patrones presentados. Dicho esto, algunos patrones usan mejor las características de Flex que otros. Tanto Presentation Model como Supervising Presenter combinan el refactoring de extracción de clase con un uso elegante de los bindings de MXML y los event handlers declarativos. Passive View y Code Behind sacrifican estas características en el beneficio de lograr una mayor separación entre ActionScript / MXML.