wpf - patron - ¿Por qué MVVM y cuáles son sus principales beneficios?

patron mvvm xamarin (6)

¿Por qué optamos por MVVM sobre MVC o MVP mientras trabajamos con WPF?

¿Qué beneficio adicional obtenemos al usar esto?

Editar:

Para ser sincero, hoy tuve una entrevista y me hicieron esta pregunta. Respondí como INotifyPropertyChanged, ICommand, IValue Convertor ... pero no estaba satisfecho. De ahora en adelante, he planteado esta pregunta

Gracias por adelantado

Baked en apoyo de ICommand y INotifyPropertyChanged son los dos mayores beneficios. Usar MVVM hace que sea muy fácil conectar los comandos y conectar datos a la interfaz de usuario de WPF. Las cosas solo funcionan.

Estos son específicos de MVVM

Aumenta la "Blendability" de sus vistas (capacidad de usar Expression Blend para diseñar vistas). Esto permite una separación de responsabilidades en los equipos que tienen la suerte de tener un diseñador y un programador ... cada uno puede trabajar independientemente del otro.
Lógica de vista "sin sentido" . Las vistas son independientes del código que se ejecuta detrás de ellas, lo que permite que la misma lógica de visualización se reutilice en varias vistas o que una vista se rehaga o reemplace fácilmente. Separa las preocupaciones entre "comportamiento" y "estilo".
No hay código duplicado para actualizar las vistas . En código subyacente, verá muchas llamadas a "myLabel.Text = newValue" rociadas en todas partes. Con MVVM puede estar seguro de que la vista se actualiza de forma adecuada simplemente configurando la propiedad subyacente y todos los efectos secundarios de visualización de la misma.
Testabilidad . Dado que su lógica es completamente independiente de su punto de vista (sin referencias de "myLabel.Text"), la prueba unitaria es más fácil. Puede probar el comportamiento de un ViewModel sin involucrar su vista. Esto también permitió el desarrollo basado en pruebas del comportamiento de la vista, lo cual es casi imposible usando el código subyacente.

Los otros dos patrones están realmente separados en términos de las preocupaciones que abordan. Puedes usar MVVM con MVP y MVC (la mayoría de las buenas muestras que hay por ahí hacen alguna forma de esto).

De hecho, MVP (con una vista pasiva, en lugar de un controlador de supervisión) es realmente una variante de MVVM, en mi opinión.

La capacidad del código XAML para el enlace de datos, así como la existencia de desencadenantes romperán los Patrones MVP y MVC.

Le indicaré un video particularmente útil de Jason Dolinger.

Viniendo de un mundo de WinForms, implementar cualquier patrón de estilo MVX me pareció más complicado de lo que valía, pero después de trabajar con WPF durante un par de años, honestamente puedo decir que no consideraría nada menos. Todo el paradigma es compatible desde el primer momento.

En primer lugar, el beneficio clave es permitir la verdadera separación entre ''vista'' y ''modelo''. Lo que eso significa en términos reales es que si / cuando su modelo necesita cambiar, puede hacerlo sin la necesidad de hacerlo y viceversa.

En segundo lugar, mientras que su ''modelo'' puede contener todos los datos que pueda necesitar en su ''vista'', es posible que desee abstraer esos datos de tal forma que su ''modelo'' no sea compatible. Por ejemplo, supongamos que su modelo contiene una propiedad de fecha. En el modelo, puede existir únicamente como un objeto DateTime pero su vista puede querer presentarlo de una manera completamente diferente. Sin el ''modelo de vista'', tendría que duplicar la propiedad en el ''modelo'' para admitir la vista o modificar la propiedad, lo que podría ofuscar seriamente el ''modelo''.

También puede usar un ''modelo de vista'' para agregar partes de su modelo que existen en clases / bibliotecas separadas para facilitar una interfaz más fluida para la ''vista''. Es muy poco probable que desee trabajar con datos en su código de la misma manera que un usuario querrá o querrá que se les presenten los datos.

Además de eso, obtienes soporte para el enlace de datos bidireccional automático entre la ''vista'' y el ''modelo de vista''.

Realmente hay un montón de cosas extra de las que podría hablar pero Jason dice que es mucho mejor que yo así que mi consejo es mirar el video. Después de unos días de trabajar así, te preguntarás cómo te las arreglaste sin él.

Buena suerte.

Personalmente, veo a MVVM no como un beneficio, sino como una obligación para aquellos que quieren usar las características geniales de WPF.

WPF está muy desarrollado con enlaces de datos en el núcleo, para permitir la separación de la interfaz de usuario del modelo. Pero la manera en que se hace técnicamente el enlace de datos en WPF es algo especial, ya que está vinculado a clases como:

DependencyProperty
INotifyPropertyChanged
ObservableCollection

Debido a esto, simplemente no se puede escribir un modelo de la manera que se desee utilizando la tecnología .NET estándar. Por ejemplo, WPF TreeView es casi imposible de usar sin usar plantillas y enlaces de datos. Simplemente no puede llenarlo simplemente como lo haría desde un modelo genérico en Winforms, por ejemplo. Debe estar vinculado a un modelo jerárquico utilizando ObservableCollection para representar los elementos secundarios de un nodo.

Digamos que V representa el código XAML y su contraparte de código subyacente (por lo tanto, está vinculado a WPF como tecnología), y digamos que M representa su modelo (por lo tanto, no está vinculado a la tecnología UI de WPF).

Bueno, nunca tendrás esto funcionando correctamente bajo WPF con solo estos V & M.

Debes agregar algo entre los dos. Algo que es compatible con WPF y entiende su modelo. Algo que habla DependencyProperty, ObservableCollection e INotifyPropertyChanged. Eso es lo que se llama VM.

Como nota al margen, una alternativa a MVVM es construir una combinación de V & M (sin plomería VM) con M que sea compatible con WPF pero aún con una independencia de UI razonable. Históricamente, ObservableCollection estaba en el ensamblado WindowsBase.dll (que se envió con WPF), por lo que realmente parecía extraño vincular un modelo genérico a algo relacionado con una tecnología de interfaz de usuario. Se ha movido de nuevo a System.dll desde entonces. Incluso entonces, a veces es difícil mantener un modelo VM puro sin ajustar la M específicamente para WPF ...

WPF tiene una mejor unión de datos que cualquier otro marco de interfaz de usuario, lo que MVVM sería ingobernable sin

MVVM proporciona capacidad de prueba unitaria y excelente agnosticismo de vista, lo que hace que sea bueno usar