MVC
ModelViewController (MVC) es un modelo de desarrollo de interfaz de usuario de computadora que separa la lógica de presentación de información y la interacción del usuario; El modelo contiene datos de aplicaciones y lógica comercial; El controlador es responsable de convertir la entrada del usuario en comandos y pasarla al modelo y ver; Esta es la explicación de Wikipedia;
Este modelo fue diseñado originalmente por Trygve Reenskaug cuando trabajaba con SmallTalk-80 (1979), y se llamó por primera vez el editor de controlador-visión modelo; Más tarde, a través de la introducción en profundidad del libro "Patrones de diseño: elementos de software reutilizable orientado a objetos", MVC se hizo completamente popular;
Comprenda las responsabilidades de compensar las tres partes de MVC y lo que los marcos JavaScript existentes nos proporcionan para que podamos usar mejor estos marcos. A continuación, primero pasaremos las tres partes que componen MVC para aprender cuáles son las responsabilidades de cada parte [dado un código de demostración con la columna vertebral como ejemplo].
Modelo
El modelo gestiona los datos de la aplicación. Cuando los datos del modelo cambian, su oyente será notificado [probablemente una vista]. Después de recibir la notificación, el oyente realizará los cambios correspondientes.
Vista
La vista es una representación visual del modelo de estado actual. La vista observará los cambios del modelo y se notificará cuando cambia el modelo, y permite que la vista se actualice. En general, usaremos el motor de plantilla para representar el modelo en la vista;
Controladores
Los controladores es un mediador entre modelos y vistas. Su trabajo es actualizar la vista cuando el modelo cambia y actualizar el modelo cuando el usuario opera la vista.
Comparación de marco de Javascipt MVC
Diferentes personas tienen diferentes métodos de comparación, la clave depende de a qué prestes atención:
1. Si presta más atención a los detalles del enrutamiento de URL del marco, el almacenamiento de datos, la implementación de la vista, etc., puede concentrarse en esto, JavaScript Throne: Framework Sword;
2. Si presta más atención a ejemplos específicos del marco, aquí hay un proyecto de código abierto que utiliza diferentes marcos de JavaScript MVC para la misma demostración. Puede ver claramente las diferencias en aplicaciones específicas de cada marco. Aquí está el sitio web oficial de ToDomVC
Los beneficios de MVC nos traen:
1. Fácil de mantener
2. El desacoplamiento de la vista del modelo significa que la lógica comercial puede probarse mejor.
3. El código se puede reutilizar mejor
4. El desarrollo modular puede aclarar la división del trabajo, algunas personas se centran en la lógica de negocios y algunas personas se centran en la interfaz de usuario.
5. Después de revisar el modelo MVC clásico, entendemos el concepto de capas en la aplicación y las responsabilidades de cada capa. Al mismo tiempo, deberíamos poder identificar las diferencias entre todos los marcos MVC JavaScript y el modelo MVC clásico que explicamos. De esta manera, al elegir el marco MVC, debemos centrarnos en cómo se implementan los modelos, vistas, controladores e incluso cómo implementar códigos específicos, para ayudarnos a elegir mejor el marco MVC JavaScript más adecuado.
MVVM
El nombre completo de MVVM es Model View ViewModel. Este modelo arquitectónico fue propuesto originalmente por Martinfowler de Microsoft como la especificación del modelo de diseño de capa de presentación de Microsoft. Es un derivado del modelo MVC. El enfoque del modelo MVVM se encuentra en las plataformas de desarrollo de la interfaz de usuario que pueden admitir la Fundación WindowsPresentation de WindowsPresentation, como HTML5, [2] [3] WindowsPressentation Foundation (WPF), Silverlight y T ZK, Adobe Flex.
La mayor parte de la implementación de este modelo se separa de otras capas al declarar la unión de datos en la capa de vista, lo que facilita la división del trabajo entre los desarrolladores front-end y los desarrolladores de back-end. Los desarrolladores frontales escriben datos vinculados a ViewModel en la etiqueta HTML. Model y ViewModel son desarrolladores de back-end que mantienen estas dos capas a través de la lógica de las aplicaciones en desarrollo.
En los últimos años, el modelo MVVM ha comenzado a implementarse en JavaScript. Actualmente, los marcos relativamente maduros incluyen knockoutjs, kendo mvvm y kockback.js. Tomemos KnockoutJS como un ejemplo para ver las responsabilidades específicas y los códigos de ejemplo de cada parte del modelo MVVM, y al mismo tiempo comprender las ventajas y desventajas de usar este modelo para desarrollar.
Modelo
Al igual que otros miembros de la familia MV*, el modelo representa los datos en un campo o datos específicos requeridos para la aplicación, un típico datos específicos de campo, como información del usuario [nombre de usuario, avatar, correo electrónico, número de teléfono] o una información musical [nombre de la canción, año de lanzamiento, álbum];
El modelo solo se centra en la información de datos y no le importa ningún comportamiento; No formatea datos ni afecta la visualización de datos en el navegador, que no es su responsabilidad; El formato de datos es la tarea de la capa de vista, y la capa lógica de negocios se encapsula en el modelo de vista para interactuar con el modelo.
Un comportamiento más inesperado realizado en la capa del modelo es verificar los datos. Por ejemplo, cuando el usuario ingrese el correo electrónico, determine si el formato de correo electrónico es correcto.
En KnockoutJS, el modelo se implementa básicamente de acuerdo con la definición anterior, pero habrá AJAX llamando al servicio del servidor para leer y escribir datos del modelo.
Vista
La vista se refiere a la parte de la aplicación que interactúa directamente con el usuario. Es una interfaz de usuario interactiva para representar el estado del modelado ViewModel. ¿La vista se considera activa en lugar de pasiva? Esta oración significa que la vista pasiva no le importa el dominio del modelo en la aplicación, y el dominio del modelo se mantiene en el controlador; La visión activa de MVVM incluye la unión de datos, los eventos y el comportamiento del modelo y el modelado debe entenderse. Aunque estos comportamientos pueden corresponder a los atributos, la vista aún necesita responder al evento de ViewModel, y la vista no es responsable de controlar el estado.
La capa de vista de KnockoutJS es un documento HTML simple, que se asociará con la declaración de datos del modelado View. Al mismo tiempo, la capa View de KnockoutJS muestra los datos obtenidos de ViewModel, pasa los comandos al Modelo View y actualiza el estado cambiado del Modelo ViewModel.
Viewmodel
Se puede considerar que ViewModel es un controlador especialmente utilizado para la conversión de datos. Puede convertir la información en el modelo en información en la vista y, al mismo tiempo, pasar comandos de la vista al modelo;
En este sentido, ViewModel se parece más a un modelo, pero controla gran parte de la lógica de visualización de la vista. Al mismo tiempo, ViewModel también expone algunos métodos para mantener el estado de la vista y actualizar el modelo de acuerdo con el comportamiento y los eventos de la vista;
En resumen, el Modelo ViewModel se encuentra detrás de la capa de UI, y exponer datos a la vista puede considerarse como la fuente de datos y comportamiento de la capa de vista;
Knockoutjs interpreta los modelos de vista como la visualización de datos y comportamientos expresados en la interfaz de usuario. No es un modelo de datos que necesita ser persistido, pero puede contener los datos almacenados por el usuario. Los ViewModels de Knockout se implementan utilizando objetos JavaScript, y no es necesario que se preocupe por las etiquetas HTML. Este método abstracto puede mantener su implementación simple.
ventaja:
1.MVVM facilita el desarrollo paralelo, de modo que los desarrolladores de desarrollo frontal y back-end no se afectan entre sí.
2. Resumen la capa de vista, reduciendo la lógica comercial en el código
3.ViewModel es más fácil de probar que el evento basado en eventos
4. La prueba de ViewModel no necesita preocuparse por la automatización e interacción de la interfaz de usuario
defecto:
1. Para una interfaz de usuario simple, usar MVVM es demasiado pesado
2. El enlace de datos declarativos no es propicio para la depuración, porque el código imperativo puede establecer fácilmente los puntos de interrupción, y este modo no es propicio para establecer tales puntos de interrupción.
3. El enlace de datos puede crear una gran cantidad de contabilidad en aplicaciones no triviales. Tampoco desea terminar con una situación más compleja en la que la unión sea más complicada que el objeto unido.
4. En aplicaciones grandes, es difícil diseñar una capa de visión del modelo de vistas antes de obtener una gran cantidad de generalizaciones.