Modelo MVC
4 Modelo MVC
4.1 Introducción
4.2 Aplicación del módelo
4.3 Estructura del sistema
4.4 Conclusiones
4.1 Introducción
El Modelo Vista Controlador (MVC) es un patrón de arquitectura de software que separa los datos de una aplicación, la interfaz de usuario, y la lógica de control en tres componentes distintos. El patrón MVC se ve frecuentemente en aplicaciones web, donde la vista es la página HTML, el control es el código que provee de datos dinámicos a la página, y el modelo contiene clases representativas de la aplicación (como el mensaje de un foro, un miembro registrado, etc.).
Modelo: Ésta es la representación específica del dominio de la información sobre la cual funciona la aplicación. El modelo es otra forma de llamar a la capa de dominio. La lógica de dominio añade significado a los datos; por ejemplo, calculando si hoy es el cumpleaños del usuario o los totales, impuestos o portes en un carrito de la compra.
Vista: Éste presenta el modelo en un formato adecuado para interactuar, usualmente un elemento de interfaz de usuario.
Controlador: Éste responde a eventos, usualmente acciones del usuario e invoca cambios en el modelo y probablemente en la vista.
Muchas aplicaciones utilizan un mecanismo de almacenamiento persistente (como puede ser una base de datos) para almacenar los datos. MVC no menciona específicamente esta capa de acceso a datos.
Es común pensar que una aplicación tiene tres capas principales: presentación (IU), dominio, y acceso a datos. En MVC, la capa de presentación está partida en controlador y vista. La principal separación es entre presentación y dominio; la separación entre V/C es menos clara.
Aunque se pueden encontrar diferentes implementaciones de MVC, el flujo que sigue el control generalmente es el siguiente:
El usuario interactúa con la interfaz de usuario de alguna forma (por ejemplo, el usuario pulsa un botón, enlace)
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.
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.
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.
La interfaz de usuario espera nuevas interacciones del usuario, comenzando el ciclo nuevamente.
4.2 Aplicación del modelo
La aplicación de este modelo y su funcionalidad depende estrechamente de la tecnología que decidamos elegir para realizar el proyecto. En el caso del desarrollo de una aplicación web como la desarrollada en este proyecto se deben tener en cuenta y aclarar aspectos que en el desarrollo de un soft de escritorio no sería necesario.
El modelo en el sistema Ninbox constituíra todos los archivos php que compondrán el dominio del sistema. Es decir, el archivo encargado de mostrar los foros, el archivo encargado de mostrar los hilos, el archivo encargado de crear una nueva respuestas..., en definitiva el conjunto de archivos que componen el nucleo lógico de la aplicación.
La vista, estará compuesta de todos los archivos plantilla, que contendrán información de presentación, es decir, serán archivos XHTML y archivos CSS que maquetarán de forma adecuada la información que se obtiene en la ejecución de cada archivo modelo.
Por último el controlador, como antes se introducía es quizá la parte del módelo que más confusión puede plantear.Para el sistema en cuestión esta parte estará compuesta por el código Javascript que será el encargado de controlar todos los eventos creados por el usuario y que intervendrán en la variación de la interfaz o en la ejecución de un nuevo archivo modelo.
4.3 Estructura del sistema
La estructura del sistema basado en MVC será la siguiente:
Modelo: los diferentes archivos php que configuran las diferentes partes del sistema, además
de las bibliotecas php necesarias para su funcionamiento.En cada uno de los modelos del sistema se importaran los sistemas de control y de vista necesarios para completar su correcta composición.Concretamente el utilizo de las plantillas será implementado mediante la librería Smarty-PHP, cuya información podemos encontrar en los apéndices.
Por otra parte la incorporación del controlador por parte de los modelos se realizara madiante la librería xajax para el control mediante AJAX y por incrustación directa de los archivos JS para los demás controladores.La referencias a la biblioteca XAJAX se encuentran en los apéndices.
Ademas se incluirán en esta parte los archivos de lenguaje que serán archivos php, según la variable de sistema lang, incorporarán un lenguaje u otro que será usado para la representación de la información.
Vista: serán las diferentes plantillas XHTML generadas según el protocolo de la librería Smarty-PHP , los archivos CSS que formatearán las plantillas.
Controlador: está compuesto por las bibliotecas JS creadas a propósito para este sistema y además se incluirá la biblioteca SCRIPTACULOUS cuya referencia se puede encontrar en los apéndices y que nos proporciona efectos dinámicos en la interfaz.
4.4 Conclusiones
Actualmente existen miles de aplicaciones web en la red, muchas de ellas realizadas con una programación desestructurada y sin diferenciación de módulos. Esto implica una difícil actualización, optimización y división de trabajo. En estos momentos las aplicaciones web están convirtiéndose en soft de gran complejidad que en ocasiones se implementan por diferentes personas, como por ejemplo el equipo de programadores y el equipo de diseñadores. Esto obliga a utilizar un modelo estructurado de programación. El modelo MVC no es el único que existe, pero nos proporciona un división tanto lógica como técnica en el sistema.
Además proporciona un medio más organizado para el diseño del sistema, permitiendo realizar aplicaciones pensadas para todos los tipos de navegadores que existen.
Sistemas tan famoso como BLOGGER, GMAIL , WIKIPEDIA... utilizan estos modelos para su implementación, están marcando el futuro del desarrollo de aplicaciones.
Aunque existen FRAMEWORKS que permiten el desarrollo de aplicaciones MVC como es por ejemplo CAKEPHP, la evolución de las webs está apuntando hacia una nueva tecnología basada en un lenguaje que pueda desarrollar por si mismo las tres partes del modelo. Obviamente existen problemas que hacen que esto no pueda ser ahora mismo viable, la parte del modelo es código ejecutado en servidor, y la parte vista-controlador es código ejecutado en el navegador. Un sistema que puede asemejarse algo más a estas premisas pueden ser las JSP ( Java Server Page ), pero también exite el problema de su desarrollo como código, según mi punto de vista Java es el lenguaje mejor diseñado de todos los que existen. Fue diseñado de manera concisa y proporciona herramientas muy potentes, pero su aspecto más poderoso que es la compatibilidad y portabilidad también genera su parte más oscura. Java fue diseñado para “todo” y para “nada” en concreto, esto implica que en aspectos más concretos como aplicaciones de escritorio o aplicaciones web, sus rivales en el caso de las aplicaciones web,como PHP, le aventajan en facilidad y rapidez de desarrollo.
La introdución ha sido extraido de Wikipedia®
El contenido está disponible bajo los términos de la Licencia de documentación libre de GNU
Copyright (C) 2005,2006 Proyecto Ninbox, Carlos Serrano Sánchez
Copias exactas y la distribución de este artículo se permiten en cualquier medio, siempre que esta nota sea conservada.
