model-view-controller - que - viewmodel mvc

Utilice patrones MVC/MVVM del lado del cliente con el patrón MVC del lado del servidor

Question

Teniendo en cuenta los patrones MVC / MVVM más populares del lado del cliente (como Knockout.js , Angular.js , Ember.js y otros), tengo una gran duda:

También considerando la redundancia de modelado en ambos lados, ¿cuáles son las ventajas y las desventajas de usar esos patrones del lado del cliente con los patrones del lado del servidor MVC?

Answer 1

Diez meses después de esta pregunta, utilicé los dos patrones dentro de la misma aplicación.

El único problema fue la necesidad de mapear los modelos dos veces.

MVC (API web ASP.NET MVC 4)

El recurso más importante fueron las rutas.

• Los modelos se crearon para las interacciones de la base de datos y como argumentos para las acciones de los controladores.
• Los controladores se crearon para manipular las solicitudes API y para representar las vistas.
• Las vistas no se modelaron con modelos del lado del servidor, sino con todos los recursos de vistas parciales y secciones.

MVVM (Knockout.js)

• Los modelos se crearon con las mismas propiedades que los modelos del lado del servidor.
• Las vistas se combinaron con las propiedades de los modelos y disminuyeron mucho el tamaño de las vistas.
• Los modelos de vista se crearon con los valores proporcionados por los métodos API.

En general, la combinación de MVC con MVVM fue muy útil, pero necesitaba una gran experiencia y conocimiento. También se requiere paciencia, porque debe pensar en las responsabilidades de cada capa de aplicación.

Answer 2

El hecho de que incorpores un modelo MVVM en un framework MVC ya implementado también es una gran cosa, recientemente agregamos knockout a algunas páginas de proyectos nuevos para que quepan en un marco MVC ya desactualizado (páginas antiguas, no el framework mismo).

Creo que MVVM es fantástico ya que la respuesta anterior indica que proporciona una experiencia de usuario excepcional con tiempos de respuesta extremadamente rápidos, puede ocultar sus llamadas de validación en el fondo sin ralentizarlas y es intuitivo.

Sin embargo, el dolor es que es MUY difícil de probar por unidad y puede obtener algunos archivos javascript extremadamente GRANDES, también la codificación adicional que hemos tenido que hacer ya que nuestros sistemas heredados todavía se ejecutan en IE6 es ridícula.

Pero MVVM y MVC no tienen que ser utilizados exclusivamente por sí mismos, utilizamos ambos. Pero tener 3 niveles de validación es algo que todavía me molesta.

Answer 3

La ventaja es que los patrones del lado del cliente son aplicables en el cliente donde el servidor no tiene alcance directo. Si está creando una interfaz de usuario HTML enriquecida e interactiva, use MVVM del lado del cliente. MVC del lado del servidor puede seguir siendo relevante en ese caso para entregar contenido apropiado al cliente. Por ejemplo, ASP.NET WebAPI es un marco para crear API API que tiene una arquitectura de controlador similar a la estructura ASP.NET MVC. La API implementada con este marco puede ser llamada por el código del lado del cliente, lo que resulta en MVC en el lado del servidor y MVVM en el lado del cliente. Normalmente, cuando se utiliza el lado del servidor MVC y el lado del cliente MVVM, las responsabilidades de los lados respectivos son muy diferentes y, por lo tanto, no hay redundancia.

Answer 4

Luché con la forma de responder a esta pregunta ... espero que esto ayude, incluso si se trata de una forma redonda.

Si bien algunos de los pros / contras ya se han mencionado, creo que el mejor resumen es en esta respuesta .

Para mí, la mayor ventaja de utilizar la lógica del lado del cliente es el rico aspecto de la interfaz de usuario.

Pero la parte clave de su pregunta parece ser "redundancia del modelo" (lo llamaría lógica duplicada, o al menos tener potencial para la lógica duplicada). En mi opinión, ese es un problema que puede existir independientemente de los pros / contra en el enlace anterior.

Entonces, en primer lugar, creo que la decisión de utilizar o no un marco del lado del cliente debe basarse en los pros y los contras bien documentados. Una vez que se toma la decisión, los problemas asociados se pueden resolver.

Supongamos que está utilizando algún tipo de marco / plataforma del lado del servidor, así como un marco del lado del cliente para proporcionar un poco de interactividad de la interfaz de usuario. Ahora hay un problema con dónde colocar la lógica del modelo: en el cliente, el servidor o ambos.

Una forma de resolver el problema es definir la lógica de su modelo solo en el cliente o el servidor. Entonces no tiene duplicación de código, pero afecta algunos de los pros / contras de nivel superior.

Por ejemplo, si la lógica de su modelo es 100% del lado del servidor, perderá parte de la parte interactiva de la interfaz de usuario. O bien, constantemente está lanzando el modelo hacia / desde el servidor, lo que tendrá algunas desventajas.

Si la lógica de su modelo es 100% del lado del cliente, podría sufrir problemas de rendimiento, dependiendo del tamaño de su vista / modelo. Esta es una de las razones por las cuales Twitter se está moviendo a un modelo de procesamiento del lado del servidor.

Luego están "ambos" ... existe una lógica de modelo tanto en el cliente como en el servidor. Creo que esta es la mejor solución, siempre que no se duplique la lógica .

Por ejemplo, en una página de carrito de compras, puede volver a calcular el costo de un pedido según el precio de un producto y un cuadro de cantidad editable por el usuario. Creo que esta lógica solo debería existir en el cliente. Es probable que otras propiedades del modelo que no cambian una vez cargadas estén bien alojadas en el servidor.

Aquí hay mucha zona gris ... Me cuesta poner todos los huevos en una sola canasta. Por ejemplo, elegir un marco del lado del cliente, crear una gran cantidad de lógica del lado del cliente, y luego [hipotéticamente] tener problemas de rendimiento, compatibilidad con el navegador o algo así. Ahora puede ajustar una página o dos para el rendimiento (como moverlo del lado del servidor, al estilo de Twitter). Pero creo que ser inteligente acerca de cómo estructurar su código ayudará a mitigar ese problema. Si su código es mantenible y limpio, mover la lógica de cliente a servidor no será difícil.

Answer 5

• ventajas
  • Esto puede rockear
• ventajas
  • Puedes atornillarlo.

Seriamente. Hacer uso del transporte de parte de la lógica de frontend en el navegador puede impulsar el desarrollo de su aplicación por qué mantiene un procesamiento de datos más estricto encapsulado en el lado del servidor.

Esto es básicamente capas. Dos capas, la anterior habla con la de abajo y viceversa:

[client] <--> [server]

Normalmente intercambia objetos de valor en un formato de serialización ligero como Json entre los dos.

Esto puede ubicar bastante bien lo que los usuarios esperan en una estructura útil, mientras que los objetos de dominio en el lado del servidor no podrían ser tan detallados.

Sin embargo, el poder real será si el lado del servidor no está escrito en JavaScript en algún punto determinado porque creo que no puede crear objetos de dominio bien allí. Considera Scala (o algo similar expresivo) entonces si te encuentras con ese problema.