Flex es un framework creado para poder llegar a usar otros frameworks. Nos centraremos en este artículo en la base de otros frameworks, como PureMVC o Cairngorm, esta característica es el patrón Módelo Vista Controlador (MVC). Analizaremos este patrón que tanto nos gusta y entonces veremos algunas otras aproximaciones para compararlas y adjuntaré proyectos de ejemplo para entender el concepto que representa cada uno.
Módelo Vista Controlador (MVC)
El Módelo Vista Controlador es el patrón arquitectural más usado en la ingeniería del software. Este patrón nos separa el modelos de datos, el modelo de la capa de presentación (vista) y de la parte de control.
De este modelo podemos decir, que gestiona la información y advierte a las otras capas de cambios en sus datos. Representa el dominio de datos. La vista representa gráficamente el modelo para que el usuario pueda interactuar él, es la interfaz de datos. El controlador recibe las peticiones de la vista y le responde actualizando el modelo de datos. Debido a que la vista observa los cambios en el modelo de datos, esta actualiza sus componentes en función de éstos.
La finalidad de este patrón será la de conseguir un bajo acoplamiento en sus aplicaciones. Este lo logra desacoplando los modelos de las vistas, reduce la complejidad en el diseño arquitectural e incrementando la flexbilidad y mantenimiento del código.
La aplicación para el ejemplo será esta:
Módelo Vista Presentación (MVP)
Este patrón es un derivado del anterior. Está centrado en la interfaz de usuario y también pensado para facilitar el la unidad de testeo y mejorar la separación conceptos en la presentación de la lógica del programa. Genera una implementación limipia del patrón Observer entre el modelo y la vista.
El modelo funciona como una interface que define los datos que serán mostrados luego en la vista. La vista es una interface que nos muestra los datos del modelo y lanza llamadas a la capa presentacion para que luego actúe con los datos. La presentacion recupera los datos del modelo y los modera y hacia la vista.
Normalmente, la vista instancia su objecto presentacion con el que se relacionará y luego le proporciona una referencia suya.
El grado de lógica permitida en las vistas variara en función de la implementación que usemos: podremos hacer que la vista sea totalmente pasiva, alegando todas las operaciones a la presentacion. Otras versiones del MVP nos permiten más autonomía a la vista.
Si nos centramos en un punto de vista de capas, la presentacion se consideraría la capa de aplicación entre el modelo y la vista.
El creador del patrón MVP, Martin Fowler, decidió separarlo en dos patrones de presentación que ya hemos tratado en madeinflex, son el supervising presenter y el passive view.
MVC vs MVP
Los une la idea de que el modelo alberga los datos y la vista los representa. Tanto el controller como el presenter se encargan de coordinar la aplicación y es en estas clases donde está la diferencia: el Presenter tiene más responsabilidades, maneja los datos del modelo y trata las propiedades de la vista que recibirá como parámetro.
Modelo Vista Adaptación (MVA)
Como en los dos patrones anteriores, se pretende separar el modelo de datos de la vista para poder realizar cambios en la vista y que estos no afecten al modelo de datos.
MVA y MVC intentan solucionar este problema con dos aproximaciones diferentes:
- MVC mantiene un estructura triangular entre el modelo, la vista y el controller, en la cual las tres entidades serían los vértices del triángulo y las aristas las vías de comunicación entre éstas.
- MVA lo soluciona de otra forma, lo hace mediante una estructura lineal en la cual en una punta estará la vista, en la otra el modelo y en el centro el adapter o mediating controller, pero se evita la comunicación directa entre la vista y el modelo.
Así pués, en este modelo, la vista está totalmente separada del modelo de datos y estas entidades sólo se pueden comunicar a través el adapter, dicho de otro modo, sólo el adapter tiene conocimiento del modelo y de la vista.
Con esta separación de comportamientos, conseguiremos que una amplia variedad de vistas puedan acceder indirectamente al modelo de datos mediante el mismo adapter. Las vistas también se olvidan del modelo de datos, ya que es el adapter quien las comunica con éste.
Esto también nos permite poder usar diferentes adapters para cada par vista / modelo. Un ejemplo podría ser la aplicación de una entidad bancaria, para cada una de sus delegaciones, puede ser que con los mismos datos y la misma vista se tengan que manipular los datos de maneras diferentes, para eso podremos tener diferentes adapters sin tener que modificar ni la vista ni el modelo de los datos.
MVA también es conocido como “mediating-controller”. Hay quien cree que como base sigue la misma idea que MVP, aunque hay gurús del software que se matan y defienden diferencias entre ellos.
Aquí os dejo un enlace de un proyecto de ejemplo para que podais analizarlo vosotros mismos.
Autor: Sergi Dote Teixidor
