El patrón de arquitectura MVC (Modelo Vista
Controlador) es un patrón que define la organización independiente del Modelo (Objetos de Negocio),
la Vista (interfaz con
el usuario u otro sistema) y el Controlador (controlador
del workflow de la aplicación).
De esta forma, dividimos el sistema en tres
capas donde, como explicaremos más adelante, tenemos la encapsulación de los
datos, la interfaz o vista por otro y por último la lógica interna o
controlador.
El patrón de arquitectura "modelo vista
controlador", es una filosofía de diseño de aplicaciones, compuesta por:
- Modelo
Contiene el núcleo de la funcionalidad
(dominio) de la aplicación.
Encapsula el estado de la aplicación.
No sabe nada / independiente del Controlador
y la Vista.
- Vista
Es la presentación del Modelo.
Puede acceder al Modelo pero nunca cambiar su
estado.
Puede ser notificada cuando hay un cambio de
estado en el Modelo.
- Controlador
Reacciona a la petición del Cliente,
ejecutando la acción adecuada y creando el modelo pertinente.
Aunque
se pueden encontrar diferentes implementaciones de MVC, el flujo que sigue el
control generalmente es el siguiente:
1.
El
usuario interactúa con la interfaz de usuario de alguna forma (por ejemplo, el
usuario pulsa un botón, enlace)
2.
El
controlador recibe (por parte de los objetos de la interfaz-vista) la
notificación de la acción solicitada por el usuario. El controlador gestiona el
evento que llega, frecuentemente a través de un gestor de eventos (handler) o
callback.
3.
El
controlador accede al modelo, actualizándolo, posiblemente modificándolo de
forma adecuada a la acción solicitada por el usuario (por ejemplo, el
controlador actualiza el carro de la compra del usuario). Los controladores
complejos están a menudo estructurados usando un patrón de comando que
encapsula las acciones y simplifica su extensión.
4.
El
controlador delega a los objetos de la vista la tarea de desplegar la interfaz
de usuario. La vista obtiene sus datos del modelo para generar la interfaz
apropiada para el usuario donde se refleja los cambios en el modelo (por
ejemplo, produce un listado del contenido del carro de la compra). El modelo no
debe tener conocimiento directo sobre la vista. Sin embargo, el patrón de
observador puede ser utilizado para proveer cierta indirección entre el modelo
y la vista, permitiendo al modelo notificar a los interesados de cualquier
cambio. Un objeto vista puede registrarse con el modelo y esperar a los
cambios, pero aun así el modelo en sí mismo sigue sin saber nada de la vista.
El controlador no pasa objetos de dominio (el modelo) a la vista aunque puede
dar la orden a la vista para que se actualice. Nota: En algunas
implementaciones la vista no tiene acceso directo al modelo, dejando que el
controlador envíe los datos del modelo a la vista.
5.
La
interfaz de usuario espera nuevas interacciones del usuario, comenzando el
ciclo nuevamente.
Comunicación
El modelo, la vista y el controlador deben
comunicarse de una manera estable los unos con los otros, de manera que sea
coherente con las iteraciones que el usuario realizara. Como es lógico la
comunicación entre la vista y el controlador es bastante básica pues están
diseñados para operar juntos, pero los modelos se comunican de una manera
diferente, un poco más sutil.
Ventajas
- La implementación se realiza de forma modular.
- Clara separación entre interfaz, lógica de negocio y de presentación.
- Sus vistas muestran información actualizada siempre.
- Cualquier modificación que afecte al dominio, como aumentar métodos o datos contenidos, implica una modificación sólo en el modelo y las interfaces del mismo con las vistas
- Las modificaciones a las vistas no afectan al modelo de dominio
- Sencillez para crear distintas representaciones de los mismos datos
- Facilidad para la realización de pruebas unitarias de los componentes.
- Reutilización de los componentes.
- Simplicidad en el mantenimiento de los sistemas.
- Facilidad para desarrollar prototipos rápidos.
- Los desarrollos suelen ser más escalables
Desventajas
- El tiempo de desarrollo de una aplicación que implementa el patrón de diseño MVC es mayor, al menos en la primera etapa, que el tiempo de desarrollo de una aplicación que no lo implementa, ya que MVC requiere que el programador implemente una mayor cantidad de clases que en un entorno de desarrollo común no son necesarias. Sin embargo, esta desventaja es muy relativa ya que posteriormente, en la etapa de mantenimiento de la aplicación, una aplicación MVC es muchísimo más mantenerle, extensible y medicable que una aplicación que no lo implementa.
- MVC requiere la existencia de una arquitectura inicial sobre la que se deben construir clases e interfaces para medicar y comunicar los módulos de una aplicación.
- Esta arquitectura inicial debe incluir, por lo menos: un mecanismo de eventos para poder proporcionar las modificaciones que genera el modelo de aplicación; una clase Modelo, otra clase Vista y una clase Controlador genéricas que realicen todas las tareas de comunicación, notificación y actualización que serán luego transparentes para el desarrollo de la aplicación.
No hay comentarios:
Publicar un comentario