prefacio
Haciendo desarrollo de clientes, el desarrollo de front-end de MVC, MVP, MVVM no entienden estos términos deben ser escuchadas, aproximadamente, arquitectura de aplicaciones se realizan para hacer frente a la complejidad de los problemas de gestión GUI aplicaciones que surgen. Muchos artículos en línea sobre esta discusión es más desordenado, todo tipo de MV diferencia entre los modos no se dicen, e incluso algunos descripción es incorrecta. Trazando el artículo fuente, desde el Smalltalk-80 patrón más clásico MVC comenzó a restaurar gradualmente interfaz gráfica bajo el MV más realista de modo.
Los problemas que enfrenta el programa de interfaz gráfica de usuario
Una interfaz gráfica a la interfaz visual aplicaciones de usuario, la interfaz a los datos y la información. comportamiento de entrada de usuario (teclado, ratón, etc.) será realizar alguna lógica de la aplicación, la lógica de aplicación (lógica de la aplicación) puede desencadenar alguna lógica de negocio (lógica de negocio) cambios en los datos de aplicación, datos de cambio necesitan naturalmente para ser sincronizado para cambiar la interfaz de usuario para para proporcionar la información más precisa. Por ejemplo, un usuario hoja de cálculo para las operaciones de reabastecimiento, la aplicación en respuesta a la operación del usuario, para ordenar los datos, entonces la necesidad de interfaz para sincronizarse a.
En el desarrollo de aplicaciones, con el fin de mejorar la gestión de la complejidad de la aplicación, la aplicación estratificada basa en la separación de funciones (speration de funciones) de pensar lo hará. En el desarrollo de aplicaciones GUI, cuando se hará la gestión del nivel de interfaz de usuario llamado Vista, datos de aplicación para el Modelo (Modelo nota aquí se refiere al modelo de dominio, los datos de la aplicación del problema que hay que resolver en abstracto, no que comprende el estado de la aplicación puede ser entendido como un objeto simple). operación Modelo proporciona datos de la interfaz, ejecuta la lógica de servicio correspondiente.
Con la vista del modelo y en capas, entonces la pregunta es: ¿Cómo Ver Sincronización Cómo se enlazan entre el modelo cambia, Vista y modelo.
Con esta pregunta comenzó a explorar el MV modo, se encuentran las diferencias entre estos modos se pueden resumir en diferentes maneras en este tema procesamiento. Casi todas las MV modelos son clásicos Smalltalk-80 versión modificada del MVC.
Smalltalk-80 MVC
Antecedentes históricos
De vuelta en la década de 1970, los Estados Unidos de Xerox Corporation (Xerox) ingenieros desarrolló el lenguaje de programación Smalltalk y comenzó a utilizarlo para escribir aplicaciones gráficas. En esta versión de Smalltalk-80, cuando un hombre llamado Trygve Reenskaug patrones ingenieros de diseño MVC aplicaciones de arquitectura de gráficos, reduce en gran medida la dificultad de gestionar las aplicaciones gráficas. Y entre la Banda de los Cuatro (GoF) patrón de diseño y no como el patrón de diseño MVC, pero sólo pensar en ello como una colección de clases para resolver el problema. MVC de Smalltalk-80 MVC y GoF describe el patrón MVC más clásico.
La dependencia de MVC
La aplicación MVC en un View, capa del Modelo, además, añade una capa Controller, sus responsabilidades y la colaboración entre una vista de modelo (enrutamiento pretratamiento de entrada) lógica de la aplicación (lógica de la aplicación); Modelo el procesamiento de la lógica de negocio. Tres niveles de dependencias Modelo, Vista, Controlador son los siguientes:
Y el Modelo Vista Controlador dependen capa, y Vista Controlador puede ser interdependientes. Las dependencias entre los datos y el controlador Ver en línea: algunos pueden no ser los mismos, algunos son de un solo sentido la dependencia, algunos son bi-dependiente, esto es en realidad poco que ver, más adelante veremos sus dependencias se procesan con el fin de comportamiento de los usuarios de gatillo evento discreción para Controller.
Llame a la relación de MVC
Después de la operación del usuario para ver, la operación Ver captura, proceso de entrega de cambio reclamará a Controller (llamadas Pass); Controlador preprocesar los datos de la vista, decidir modelo que las llamadas de interfaz; a continuación, lleva a cabo por una correlación del Modelo la lógica de negocio, y cuando el modelo cambia más tarde, será notificado por el observador Ver modo (patrón de observador), y más tarde recibió un modelo de mensajes Ver cambia según el modo observador, solicitar los datos más recientes de modelo, y luego re-actualización de la interfaz. La figura siguiente:
Que parecía no tener lugar en particular, sino que requieren una atención especial por varios puntos clave:
Ver es cambiar el control al controlador, controlador ejecuta la lógica de aplicación asociada con la aplicación (de la vista para preprocesar los datos, decidir qué interfaz de llamadas modelo, etc.).
Controlador de operación Modelo, Modelo ejecuta la lógica de negocio para procesar los datos. Pero no opera directamente Ver, se puede decir que es una vista en la ignorancia.
Ver modelo de mensaje de sincronización y se lleva a cabo por el patrón de observador, y la sincronización de datos Modelo Vista por su petición de ver y actualizar.
De particular interés es la esencia del patrón MVC es que el tercer punto: Modelo actualizaciones son informados por el modo observador Vista, la forma específica de expresión puede ser un pub / sub o activar eventos. Y muchos descripción en línea para MVC no hizo hincapié en este punto. Es a través de los beneficios del patrón de observador: Diferentes triángulo MVC puede tener un modelo común, un triángulo en el Modelo del controlador MVC después de la operación, dos MVC Triángulo Ver recibirán una notificación, a continuación, actualice a sí mismo. El mantenimiento de un dependiente con un modelo de vista diferentes pantallas en tiempo real y exactitud de los datos. Estamos en el modo observador para ser utilizado, hace décadas se ha integrado en el diario del gran Dios que entre la arquitectura MVC.
Hay un patrón de MVC JavaScript Demo, para lograr unas pequeñas aplicaciones ToDoList. El Smalltalk-80 clásico marco MVC no requiere ningún tipo de apoyo se puede lograr. marco de front-end web que actualmente afirma ser el único que seguir estrictamente las Smalltalk-80 MVC patrón: maria.js.
fortalezas y debilidades de MVC
ventajas:
La lógica de negocio y la separación lógica de presentación, un alto grado de modularidad. Y cuando la lógica de la aplicación necesita ser cambiado, sin cambiar la lógica de la lógica de negocio y presentación, sólo tienen que sustituir a otro controlador de controlador en la línea (Controlador intercambiable).
El patrón de observador puede hacerse simultáneamente actualizar varios puntos de vista.
desventajas:
1.Controller difícil prueba. Debido a que el funcionamiento síncrono vista es realizada por verse a sí mismos, y Vista sólo se ejecutan en presencia del medio de interfaz de usuario. Tiempo para la unidad de controlador de prueba en ausencia de entorno de interfaz de usuario, la lógica de aplicación es incapaz de verificar la exactitud de: actualización del modelo, no puede actualizar la vista afirma.
No 2.View componentización. Ver depende en gran medida del modelo en particular, una aplicación adicional del conjunto reutilizable a cabo difíciles si es necesario ya que este punto de vista. Debido a los diferentes programas modelo de dominio no son los mismos
MVC Modelo 2
Cuando el desarrollo del lado del servicio Web entrará en contacto con el patrón MVC, y este patrón no puede ser estrictamente llamado patrón MVC MVC. El patrón clásico MVC acaba de resolver el problema de las aplicaciones GUI del cliente, mientras que el servidor no es válido. El lado del servicio del patrón MVC tiene su propio nombre específico: MVC Modelo 2, o llamar a la JSP Modelo 2, o es directamente Modelo 2. Modelo modo de interacción entre el servidor 2 cliente de la siguiente manera:
Servidor recibe la solicitud, el servidor desde el cliente a la solicitud de encaminamiento de reglas de transformación contemplado específico Controller, controlador ejecuta la lógica de aplicación correspondiente, la operación del modelo, después de la ejecución de la lógica de negocio Modelo; y datos para prestar específica plantilla, se devuelve al cliente.
Debido a que el protocolo HTTP es un protocolo simple y no tiene estado, el servidor no puede enviar datos directamente al cliente. A menos que el cliente inició la solicitud de nuevo, o el modelo de servidor de cambio no puede decirle al cliente. Así se puede ver el clásico de Smalltalk-80 MVC informar a la vista del modelo de actualizar este anillo está rompiendo sin piedad a través del modo de observador, no se puede llamar una estricta MVC.
modelo Modelo 2 se aplicó por primera vez en 1998 en aplicación JSP que, JSP Modelo caos gestión 1 aplicación inducida por la referencia al cliente modelo JSP MVC, dio origen a la Modelo 2.
A finales de este modelo se aplica en casi todos los idiomas marco de desarrollo Web. ThinkPHP, Dijango de Python, Frasco, nodejs el Express, Ruby RoR PHP, y básicamente adoptó este modelo. Por lo general, hablando de MVC es este lado servicio básico de la MVC.
MVP
MVP en dos modos:
Ver pasiva
supervisar Controller
Los patrones pasiva Vista se discuten en la mayoría de los casos. modo de PV en el presente documento más detallada descripción, el modelo SC se menciona brevemente.
Antecedentes históricos
modo de MVP es un patrón MVC modificado. En la década de 1990, IBM subsidiaria Taligent propuesto a la vez con el desarrollo de la C / C ++ de una interfaz gráfica llamada sistema de aplicación CommonPoint.
MVP (Ver pasiva) la dependencia
modo de MVP el modo MVC Controller sustituye Presentador. Las dependencias entre nivel MVP como sigue:
MVP rompió el Modelo Vista dependencia original en el resto de las dependencias patrón MVC y consistente.
MVP (Ver pasiva) la relación de llamadas
Desde Ver dependencia de Modelo se rompe, entonces cómo sincronizar modelo de vista los cambios? Echar un vistazo a la relación entre el MVP de las llamadas:
Y el modelo MVC, los usuarios va a pagar por la operación de Vista a cambio de presentador. Presentador llevará a cabo la lógica de la aplicación apropiada y sobre las medidas apropiadas modelo, pero esta vez después de la finalización de la ejecución de la lógica de negocio modelo, sino también por el modo de observador a cambiar su propia mensajería, pero en su lugar se pasó la vista del moderador. Presentador llegar el mensaje cambia de modelo después de una actualización de la interfaz a través de la interfaz de Vista.
Puntos clave:
Ver lógica de sincronización ya no es responsable, sino por el presentador. Presentador tanto en la lógica de la aplicación también tiene lógica de sincronización.
Ver una necesidad de proporcionar una interfaz para el usuario interfaz de llamada Presentador. (Key)
comparativo En MVC, Controller es inoperante a View, Vista no proporciona una interfaz correspondiente;
En el MVP de ellos, pueden ser operados vista del moderador, Vista proporciona un conjunto de interfaces necesarias para el funcionamiento de la interfaz de ser llamado Presentador; Modelo siendo transmitido en el evento a través de sus propios cambios, pero escucha y no por la vista del moderador.
MVP (pasivo) Ver ventajas y desventajas
ventajas:
Fácil de prueba. Presentador de interfaz de Vista por, cuando no depende del entorno presentadora de interfaz de usuario para las pruebas unitarias. Mock por un objeto View que sólo necesidad de implementar la interfaz de Vista puede ser. Presentador se inyecta entonces en la dependencia, cuando la unidad de prueba puede probar la lógica de la aplicación completa Presentador corrección. Éstos son ejemplos unidad Presentador pruebas de acuerdo con el ejemplo anterior.
Vista de los componentes se puede realizar. Entre el MVP, Vista no depende del modelo. Esto permite Ver escindió de un escenario de negocio en particular, se puede decir View puede hacer negocios completamente ignorantes. Sólo se necesita para proporcionar una gama de interfaz para la operación de capa superior. Esto puede hacerse Ver componentes altamente reutilizables.
desventajas:
Presentador además de la lógica de la aplicación, hay una gran cantidad de Ver-> Modelo, Modelo-> Ver la lógica de sincronización manual, lo que resulta presentador relativamente pesado, sería más difícil de mantener.
MVP (supervisor Controller)
Se mencionó anteriormente es el modo MVP pasiva, Vista muy pasiva En este modo, es casi no sé nada, Presentador que sea lo que está haciendo. El modo de mando a Supervisar, Presentador será parte de una lógica de sincronización sencilla para ver a sí mismo a hacer, Presentador responsable sólo de la más compleja operación de la interfaz de usuario de alto nivel, por lo que se puede ver como un controlador de supervisión.
Dependencia y las relaciones de llamada en el patrón Controlador Supervisor:
Supervisar Controller ya que con menos, su muy discutido aquí
MVVM
Antecedentes históricos
Microsoft patrón MVVM fue propuesto por primera vez, y el uso extensivo de WPF y .NET en Sliverlight. En 2005, el ingeniero John Microsoft Gossman en su blog por primera vez publicado el patrón MVVM.
ViewModel
MVVM es representativa del Modelo-Vista-ViewModel, aquí es necesario explicar lo que es modelo de vista. Modelo de vista es el significado de "Modelo de Vista", la vista del modelo. Su significado incluye el modelo de estado de dominio (Domain Model) y vistas (Estado). En la interfaz gráfica de entre las aplicaciones, información de la interfaz proporcionada no puede contener modelo de dominio de la aplicación. También puede contener algo del modelo de dominio estado de vista no incluye, por ejemplo, un programa de hoja de cálculo que se mostrará en el estado de la orden actual o en orden inverso, que no está incluido en el modelo de dominio, sino también la necesidad de información de la pantalla.
Modelo de vista puede entenderse simplemente como el contenido de la pantalla de resumen de datos y modelo de dominio no es la misma página, es más adecuado para la descripción Ver modelo de vista.
dependencia MVVM
La dependencia MVVM y MVP dependiente, pero se sustituye por el P VM.
Llame a la relación MVVM
relación de llamadas MVVM y MVP misma. Sin embargo, habrá un modelo de vista que se pedía Binder, o algo por el motor de enlace de datos. Los datos previos entre toda la responsabilidad del proceso de sincronización de vista del moderador y modelo a que se refiere Binder. Sólo se necesita la sintaxis de la plantilla de vista entre la Directiva declara un contenido que aparece en la vista y cuál es el enlace de datos del modelo. Cuando ViewModel Modelo tiempo de actualización lleva a cabo, los datos de actualización Carpeta pasará automáticamente a Vista, Vista cuando el usuario acciona (por ejemplo, entrada de formulario), Carpeta actualizará automáticamente los datos al modelo. Esto se llama: dos direcciones enlace de datos, el enlace de datos bidireccionales. Simplemente no puede ser entendida como un motor de plantillas, pero será dictada en tiempo real basado en los cambios de datos.
En otras palabras, MVVM automatizar la lógica de sincronización en la Vista y el Modelo. Presentador anteriormente responsable para la vista y el modelo de sincronización ya no es operar manualmente, pero se hace referencia al marco proporcionado por Binder a cargo. Sólo decirle Binder, muestran datos correspondientes Ver modelo que forma parte de la lata.
MVVM ventajas y desventajas
ventajas:
Mejorar la mantenibilidad. MVP resolver un gran número de problemas de sincronización manual y modelo de vista y proporcionar mecanismo de unión de dos vías. Mejorar la capacidad de mantenimiento del código.
Simplificar las pruebas. Porque la lógica de sincronización es entregado a hacer Carpeta, Ver Modelo cambia seguir al mismo tiempo, sólo es necesario para garantizar la exactitud del modelo, Vista a la derecha. reduciendo en gran medida la prueba de Vista de actualización de sincronización.
desventajas:
Demasiado simple interfaz gráfica no se aplica, o que un exceso.
Para aplicaciones de gráficos grandes, ver estado grande, construir y mantener el coste modelo de vista será relativamente alta.
declaración vinculante datos se escriben en el imperativo Ver las plantillas entre las que el contenido hay manera de jugar el punto de interrupción de depuración.
epílogo
Se puede observar a partir MVC-> MVP-> MVVM, como un proceso de actualización Daguai. Este último resuelve el problema de la herencia de los primeros, las deficiencias de la antigua optimización se ha convertido en ventajas. Demostración misma función, el código desde el principio de un montón de archivos, la optimización se convirtió en las últimas líneas de necesidad código sólo 20 completaron. La distinción entre MV * modo es bastante claro, y espero que pueda entender estos patrones a referencias más oscuras y compañeros aportan algunas ideas.
Este artículo se reproduce desde debajo de la interfaz: restaurar el verdadero patrón de MV *