MVP Vs MVVM: por qué

Question

Estaba usando MVP cuando estaba trabajando con winform. pero me mudé a MVVM cuando comencé a jugar con WPF o Silverlight.

Lo único que noté es que no necesitamos sincronizar los datos entre View y ViewModel en el patrón de MVVM debido a un enlace poderoso.

Mi pregunta es ~

1) Encuadernación (que nos ayuda a no sincronizar manualmente Ver y modelo de vista) es la única ventaja de usar MVVM.

2) ¿Hay alguna otra ventaja MVVM sobre MVP? ¿Cuáles son las diferencias?

3) ¿El código siguiente es patrón MVVP o MVVM o ambos?

interface IView{ 

    void ShowMessage(string message); 

} 

class View : IView { 
    public void ShowMessage(string message){ 
       MessageBox.Show(this, message); 
    } 
} 

class ViewModel{ 

private IView view; 

public ViewModel(IVew view){ 

    this.view = view; 

} 

........ 

view.ShowMessage("This is a msg"); 

} 

Gracias.

Answer 1

Ejemplo es MVP, claramente definido por esta línea:

view.showMessage("This is a msg"); 

mientras que el código resultante de MVP y MVVM puede ser similar en los ejemplos triviales, esos patrones son significativamente diferentes. Si sospecha que MVVM es solo el nombre de Microsoft para MVP, no lo es.

Es el nombre de Microsoft para un patrón menos conocido de PM (Modelo de presentación); es posible que desee leer su descripción.

Answer 2

Me doy cuenta de que su pregunta se ha formulado hace dos años, pero me gustaría dar mi opinión después de trabajar con MVVM durante más de un año.

-1- No estoy seguro de lo que está preguntando pero creo que está preguntando: ¿Es la única ventaja vinculante para MVVM? La respuesta es no. La separación de las inquietudes, las pruebas vinculantes y eficientes son los principales beneficios para MVVM. Hay muchos beneficios menores, pero no entraré en ellos. La vinculación es absolutamente maravillosa porque todas las sincronizaciones están automatizadas, lo que significa menos trabajo para usted. Además, la separación de preocupaciones significa que el modelo de vista no depende del tipo de vista, por lo que puede tener múltiples vistas usando el mismo modelo de vista. Digamos, por ejemplo, que creas un modelo de vista llamado ErrorDataViewModel. El objetivo de esta clase es mantener una lista de clases ErrorType que se mostrarán al usuario. El ErrorType básicamente muestra información de error. El ErrorDataViewModel también tiene una propiedad booleana llamada AllErrorsFixed que le permite al usuario saber si se han corregido todos los errores en la lista. AllErrorsFixed es una propiedad simple que usa linq para consultar la lista de ErrorTypes.Fixed property. Si Todos son corregidos, AllErrorsFixed devolverá verdadero.

En la Aplicación1, su cliente quiere que los errores se muestren en una forma simple de cuadrícula. Todo lo que haces es vincular una grilla a la lista de errores de ese modelo de vista. En Application2, su cliente quiere que los errores se muestren en un formato de navegación en el que pueda ver cada formulario de error por formulario. Todo lo que hace entonces es vincular el control de su formulario a cada error en la lista y configurar su navegación para pasar de un registro a otro. Pero espere, si queremos que App1 utilice una cuadrícula y una navegación forma por forma, podemos hacer eso. Aún mejor, ahora que desea implementar una interfaz web usando Silverlight para reemplazar Application1/Application2 o como otra oferta de producto, no tiene que cambiar el modelo de vista. El trabajo está hecho.

Mencioné el valor booleano ErrorsFixed, bueno, olvidamos implementar eso en nuestras aplicaciones. Todo lo que tengo que hacer es ir a mis vistas, agregar un control o una columna o un probador de propiedades y vincularlo a la propiedad booleana y listo.

En cuanto a las pruebas, las pruebas pueden ser más eficientes porque puede escribir código de prueba para validar los cambios dentro del modelo de vista sin perder tiempo ejecutando las aplicaciones y abriendo las vistas. Esto no resuelve todos los problemas de prueba pero elimina muchos pasos que consumen mucho tiempo.

-2- ¿Hay alguna ventaja para MVVM o MVP. Sí. Un póster era incorrecto al decir que una vista puede tener varias máquinas virtuales en MVVM. En realidad, una VM puede tener múltiples vistas porque no está vinculada a una vista. O dicho de otra manera, las vistas múltiples pueden utilizar una máquina virtual. Entonces, en su ejemplo donde llama a view.ShowMessage(), esto no sucedería en MVVM porque no puede garantizar que la vista (WPF o Silverlight o clase de prueba) tenga un método ShowMessage. En cambio, disparas un evento. De hecho, Prism es asombroso con esto porque tiene agregadores de eventos, por lo que cuando activa un evento, el agregador de eventos maneja el envío del evento a la Vista asignada al evento. Por lo tanto, la vista de cada aplicación puede manejar el evento como mejor le parezca. Con MVP, debe crear un presentador para cada vista. Esto es extremadamente lento.

-3- Su código de ejemplo es MVP.

Answer 3

que han respondido a algunas pregunta similar antes, pero que podría ser útil para usted también:

Las principales características de ambos para su uso en el entorno Android.patrón

MVP:

• Consta de Modelo, Vista, y las capas del presentador;

• Ver delegados de entrada del usuario al presentador; ambas capas deben tener una relación de 1 a 1;

• La vista y el modelo no están estrechamente acoplados para una separación clara de
  preocupaciones;

• Ver conecta con el modelo mediante la unión directa de datos;

• Fácil prueba de la unidad, como una interfaz para la capa del presentador uno puede burlarse rápidamente; patrón

MVVM:

incluye tres partes principales:

• Modelo (de reglas de negocio, acceso a datos, clases),

• Ver (interfaz de usuario),

• ViewModel (como agente entre la vista y modelo);
• La mejor solución para manejar las tareas relacionadas con el sistema de Windows Presentation Fundación (WPF) y Silverlight marco de aplicación;
• Proporciona una separación más clara de la IU y la lógica de la aplicación;
• Prueba de la unidad sea aún más fácil, ya que no hay dependencia de la vista

Comparación de características

Vamos a poner juntos los elementos esenciales de MVP vs MVVM para comparar. También debemos enfatizar que no estamos abogando por uno o patrón.

Métricas de código: MVP puede producir más clases y código Java. En MVVM hay más clases de Java pero menos código por clase.

Capacidad de mantenimiento: MVP es fácil de aprender, modificar y agregar funciones. Agregar nuevas características con MVVM puede requerir cierta experiencia con la biblioteca.

Lógica: en MVP la Vista es en realidad su aplicación mientras Presenter maneja el flujo de la aplicación. En MVVM, las clases de código (ViewModel) son la aplicación, mientras que View es la interfaz que permite a los usuarios interactuar con la aplicación.

Entrada de datos: Comienza con la vista en MVP, no en el presentador. La entrada en MVVM comienza con View, no con ViewModel.

Asignación y referencias: Cartografía uno a uno entre la Vista y el Presentador en MVP, sin referencia entre ellos. Mapeo Uno a Muchos entre la Vista y el Modelo de Vista en MVVM, sin referencia.

Palabras finales

Evidentemente, los patrones arquitectónicos evolucionan. MVVM tiene la tendencia de convertirse en una herramienta realmente ordenada y aprehensiva. Mientras tanto, el patrón MVP es lo suficientemente flexible como para beneficiarse de varias bibliotecas.

Lo que también está claro es que no tiene que apegarse estrictamente a MVP o MVVM. En la mayoría de los casos, no podemos construir una aplicación puramente en un solo patrón, y eso está bien. Lo principal es separar la vista, el modelo y la lógica entre ellos.

¿Cuándo usar MVP y cuándo usar MVVM, puede preguntar? El consejo se esconde más bien en el enlace de datos. En los casos en que no es posible enlazar con el contexto de datos, la mayoría de los desarrolladores prefieren MVP (Windows Forms es un gran ejemplo). MVVM es de preferencia en los casos en que es posible enlazar con datacontext, ya que hay menos interfaces y menos código para mantener.

por los materiales de la blog

Answer 4

Tanto MVP y MVVM son derivados de MVC (ver líneas de tiempo y cómo éstas han evolucionado). La diferencia clave entre ellos es la dependencia que cada capa tiene en otras capas, así como cuán estrechamente vinculadas están entre sí.

MVC: Biblioteca Marco

lado del cliente Backbone.js, knockback.js, Spine.js, angularjs.

lado del servidor ASP.NET MVC, Spring MVC, Ruby-on-Rails

MVP: Biblioteca Marco

lado del cliente Riot.js, GWT

lado del servidor ASP.NET , JSP Servlets

MVVM: Biblioteca Marco

lado del cliente Knockout.js, Kendo (MVVM)

lado del servidor WPF (escritorio) o Silverlight, las aplicaciones de Windows Phone (XAML), Adobe Flex

Así que para responder a la pregunta específica: sí, excepto el enlace bidireccional en MVVM, ViewModel expone un Observable que es la principal ventaja de MVVM que vincula datos bidireccionales.