MVC modelo vista controlador
El patrón modelo vista controlador (MVC abreviado en Inglés model-view-controller), como patronos modelo vista presentación o presentación- abstracción control, es un modelo para satisfacer las necesidades de las aplicaciones interactivas la separación de los asuntos relacionados con los diferentes componentes en sus respectivas arquitectura.
Este paradigma incluye las funciones necesarias en tres categorías:
– un modelo (modelo de datos);
– vistas (presentación, la interfaz de usuario);
– un controlador (lógica de control, gestión de eventos, la sincronización).
La organización de una interfaz gráfica de usuario es complicado. La arquitectura MVC no pretende eliminar a todos los problemas, pero ofrece una primera aproximación a hacer esto. Proporcionar un marco normalizado para estructurar una aplicación, sino que también facilita el diálogo entre los diseñadores.
La idea es separar los datos, presentación y tratamiento. Esto se traduce en que las tres partes mencionadas anteriormente: Modelo, Vista y Controlador.
Modelo MVC
El modelo representa el corazón (algorítmicos) de aplicación: procesamiento de datos, la interacción con la base de datos, etc. Se describen los datos manipulados por la aplicación. Incluye la gestión de estos datos y es responsable de su integridad. La base de datos es uno de sus componentes. El modelo incluye los métodos estándar para la actualización de los datos (insertar, eliminar, cambiar de valor). También proporciona métodos para recuperar los datos. Los resultados devueltos por el modelo no están involucrados en la presentación. El modelo contiene ninguna relación directa con el controlador o vista. La comunicación con la visión se produce a través del patrón Observer.
El modelo puede permitir múltiples vistas parciales de datos. Si por ejemplo el programa maneja una base de datos para los horarios, el modelo puede tener métodos para todos los cursos de una habitación, todo sobre una persona o todos los cursos de un grupo de TD.
Vista MVC
La que el usuario interactúa con precisión los nombres de la vista. Su primera tarea es presentar los resultados devueltos por el modelo. Su segunda tarea es conseguir que cualquier acción por parte del usuario (flotar, clic, seleccionar un botón de radio, selección de una casilla de verificación, el ingreso de texto, movimiento, voz, etc.). Estos eventos se envían al controlador. La vista no lleva a cabo el tratamiento, sólo imprime los resultados del proceso realizado por el modelo e interactuar con el usuario.
Múltiples puntos de vista pueden mostrar información parcial o no del mismo modelo. Por ejemplo, si una aplicación de conversión de base de datos tiene un solo entero como dado, el mismo entero puede mostrarse de muchas formas (texto en diferentes bases, poco a poco con la caja de botones, con deslizadores). La vista también puede proporcionar al usuario la capacidad para cambiar de vista.
Controlador MVC
El controlador es compatible con la gestión de eventos de sincronización para actualizar la visión o modelo y sincronizar. Recibe todos los acontecimientos de la vista y se involucra las acciones a realizar. Si una acción requiere un cambio de los datos, el controlador pide la modificación del modelo de datos de modo que la actualización de los datos se muestra. De acuerdo con el patrón de diseño, la vista es un «observador» del modelo que es «observable». Alguno evento de usuario no se refiere a los datos, pero la vista. En este caso, el controlador pidió el cambio. El controlador realiza ningún procesamiento, ni modifica ningún dato. Se analiza la solicitud del cliente y simplemente llamar el modelo apropiado y vuelve la vista para la aplicación.
Por ejemplo, en el caso de una base de datos que gestiona los horarios de los profesores de una escuela, una acción del usuario puede ser la entrada de un nuevo curso. El controlador agrega el modelo actual y exige su reconocimiento por la vista. Una acción de usuario también puede seleccionar una nueva persona para ver todos los cursos. Esto no cambia la base de los precios sino que únicamente exige que la visión se adapte y ofrece al usuario una visión de ser esa persona.
Cuando el mismo objeto controlador recibe eventos para todos los componentes, se debe determinar el origen de cada evento. Este tipo de eventos puede ser tedioso y puede conducir a un cierto código. Por lo tanto el controlador a menudo se divide en varias partes, cada una de las cuales recibe el evento algunos de los componentes.
Procesamiento de flujo MVC
En resumen, cuando un cliente envía una petición a la aplicación:
– La solicitud enviada desde la vista es analizada por el controlador (por ejemplo, un clic del ratón para lanzar un procesamiento de datos);
– El controlador preguntó al modelo apropiado para llevar a cabo el tratamiento y notificar a la opinión de que la solicitud se procesa («vía», por ejemplo, un controlador o de devolución de llamada);
– La vista notificada hace una petición al modelo para actualizarse (por ejemplo, muestra el resultado del tratamiento «a través» del modelo).
Beneficios MVC
Una ventaja proporcionada por este modelo es la claridad de la arquitectura que impone. Esto simplifica la tarea del desarrollador de intentar realizar el mantenimiento o la mejora en el proyecto. De hecho, los cambios en el tratamiento no cambia la vista. Por ejemplo, puede pasar una base de datos tipo SQL con XML, simplemente cambiando la interacción tratamiento con la base, y las vistas no por ello puede verse afectada.
El VMC sus límites en el contexto de las aplicaciones que utilizan las tecnologías web, construidos a partir de los servidores de aplicaciones. Las capas adicionales se introducen entonces y la inversión de los mecanismos de control y de inyección de dependencia.
Diferencia con la arquitectura de tres niveles
La arquitectura de tres niveles es un modelo de capas, es decir, cada capa sólo se comunica con sus capas adyacentes (superior e inferior) y el flujo de control a través del sistema de arriba hacia abajo; las capas superiores de control de las capas inferiores, es decir, las capas superiores son siempre fuentes de interacción (clientes), mientras que las capas inferiores sólo están respondiendo a las solicitudes (servidores).
En el patrón MVC, se acepta generalmente que la vista puede referirse directamente al modelo (reproducción) sin utilizar el controlador. Por contra, tiene que pasar necesariamente por el controlador para hacer un cambio (escritura). Aquí, el flujo de control se invierte en comparación con el modelo de capas, el controlador puede enviar peticiones a todas las vistas de modo que se actualizan.
En la arquitectura de tres capas, si miras cambia los datos, todas las vistas afectadas por la modificación deben actualizarse, por lo tanto, la utilidad de usar el MVC en la capa de presentación. La capa de presentación hace posible el establecimiento de normas tales como «puntos de vista de actualización sobre X si Y o Z se cambian.» Pero estas reglas se están convirtiendo rápidamente demasiado numerosos e inmanejable si las relaciones lógicas son demasiado altas. En este caso, una actualización sencilla en vistas intervalos regulares hace que sea fácil de superar este problema. También es la solución más extendida en la arquitectura de tres niveles, el uso de MVC es moderno y todavía marginal.