Model–View–Controller y algunas de sus variantes

Flex es un framework pensado para poder usar otros frameworks. En este artículo nos centraremos en la base de muchos frameworks, como Cairngorm o PureMVC, esta característica es el patrón Model-View-Controller (MVC). Analizaremos este patrón y veremos otras aproximaciones para compararlas y adjuntaré proyectos de ejemplo para entender el concepto que representa cada uno.

Model–View–Controller (MVC)

Como ya sabemos, es un patrón arquitectural muy usado en la ingeniería del software. Este patrón nos separa el modelos de dato, de la capa de presentación y de la parte de control.

El modelo controla la información y notifica a sus observadores de cambios en sus datos. Representa el dominio de datos. La vista representa gráficamente el modelo para que el usuario pueda interactuar él. El controlador recibe peticiones de la vista y responde actualizando el modelo de datos. En consecuencia, debido a que la vista observa cambios en el modelo de datos, actualiza sus componentes en función de éstos.

La finalidad de este patrón es conseguir bajo acoplamiento en las aplicaciones. Lo logra desacoplando los modelos de las vistas, reduciendo la complejidad en el diseño arquitectural e incrementando la flexbilidad y mantenimiento del código.

La aplicación de ejemplo que usaremos es esta:

A continuación os dejo el proyecto que la implementa según MVC.

Model-View-Presenter (MVP)

Este patrón se considera una derivación del MVC. El patrón MVP está centrado en la interfaz de usuario y pensado para facilitar el unit testing y mejorar la separación conceptos en la presentación de la lógica. Proporciona una implementación limipia del patrón Observer entre el modelo y la vista.

El modelo es una interface que define los datos que serán mostrados en la vista. La vista es una interface que muestra los datos del modelo y lanza llamadas a la capa presenter para que actúe con los datos. El presenter recupera los datos del modelo y los persiste y hacia la vista.

Normalmente, la vista instancia su objecto presenter con el que se relacionará y le proporciona una referencia suya.
El grado de lógica permitida en las vistas varia en función de la implementación que usemos: podemos hacer que la vista sea totalmente pasiva, alegando todas las operaciones al presenter. Otras versiones del MVP permiten más autonomía a la vista.

Si nos centramos en un punto de vista de capas, el presenter 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.

Aquí está el proyecto implementado con MVP.

Model–View–Adapter (MVA)

Como en los dos patrones anteriores, quiere separar el modelo de datos de la vista para que los cambios en la vista no afecten el manejo de datos y que éstos puedan ser tratados sin cambiar la interfaz de usuario.

MVA y MVC intentan solucionar este problema con dos aproximaciones diferentes:

• MVC mantiene un estructura triangular entre el modelo, la vista y el controller, donde 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 manera diferente, lo hace mediante una estructura lineal en la cual en una punta está la vista, en la otra el modelo y en el centro el adapter o mediating controller, pero se evita la comunicación directa entre el modelo y la vista.

Así pués la vista está totalmente desacoplada del modelo de datos y estas entidades sólo se pueden comunicar mediante el adapter, en otras palabras, sólo el adapter tiene conocimiento del modelo y de la vista.

Con esta separación de comportamientos conseguimos 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 modelo / vista. 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 maipular los datos de maneras diferentes, para eso podríamos tener diferentes adapters sin tener que modificar ni la vista ni el modelo de 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 defienden diferencias entre ellos.

Aquí os dejo un enlace de un proyecto de ejemplo para que podais analizarlo vosotros mismos.

Conclusión

En este artículo hemos recordado el patrón MVC y visto dos enfoques que derivan directamente de él, para poder comparar la manera de abordar la relación modelo-vista-controlador. Espero que haya sido de vuestro interés.