¿Cuáles son los problemas del patrón MVVM?

Question

¿Model-View-ViewModel es el mejor patrón para usar en WPF? ¿Hay algún inconveniente?

Answer 1

Aquí hay una buena y breve publicación de blog en el advantages and disadvantages of MVVM, directamente del propio John Gossman.

Sus principales desventajas son:

"Para sencilla interfaz de usuario, MV-VM puede ser excesiva En los casos más grandes, puede ser difícil de diseñar el modelo de vista en la delantera con el fin de obtener la cantidad adecuada de generalidad de datos.. -encuadernación para todas sus maravillas es declarativo y más difícil de depurar que cosas imperativas donde simplemente estableces puntos de interrupción "

Answer 2

Sí, es una exageración para pequeñas aplicaciones de estilo hola mundo.

Answer 3

Es un gran patrón y francamente uno de los pocos patrones de UI eliminados para WPF. Lo que quiero decir con eso es que muchas personas lo entienden y lo han adoptado. Por lo tanto, es relativamente fácil obtener ayuda e información sobre él.

El mayor inconveniente en mi opinión es que aumenta el número de clases y componentes en su aplicación, porque SRP supera en este patrón. Dicho esto, creo que vale la pena.

Answer 4

Para construir nuestra aplicación, comenzamos con MVVM, pero después de tener muchos problemas nos damos por vencidos en MVVM por motivos que identificarán dónde no usar MVVM.

Herencia Problema

Programamos en .NET, y usamos C# y mejor Claro que queremos herencia. C# no es compatible con la herencia de clases múltiples, por lo que no podemos tener clases abstractas con lógica que se reutilizarán parcialmente en la IU y en la lógica.

La mayoría de las veces estamos confundidos, cómo diseñar modelos de vista para que podamos heredar y controlar la lógica.

Si heredamos la Vista, no podemos heredar ViewModel al mismo tiempo, y si heredamos ViewModel, entonces no podemos heredar la Vista al mismo tiempo. En cambio, tenemos que usar genéricos muy complicados y con la ayuda de herramientas como Prism y Unity que podemos lograr, pero no vale la pena el tiempo.

modelo de vista de modelo de vista Encuadernación

bien la mayor parte de la lógica de negocio el tiempo isnt tan simple como A = B + C, interfaz de usuario y la respuesta de la interfaz de usuario juega un papel muy importante. Sin embargo, podemos vincular las propiedades visuales de la interfaz de usuario a las propiedades de datos del modelo de visualización, pero surge la pregunta de cómo vincular realmente un modelo de vista a otro modelo de vista y si pasan por dos enlaces de controles compartidos, entonces no tenemos idea de qué se ejecutará primero.

modelo de vista no es simple sustitución de CodeBehind

Se supone que ViewModel es simple sustitución de archivos CodeBehind. Pero al crear nuestra aplicación, la restricción de herencia nos enseñó que, como WPF/Silverlight admite UI Style, que puede separar por completo la IU con lógica, estamos por encima de separar la lógica empresarial en ViewModel.

Código repetida en el modelo de vista

Finalmente nos dimos cuenta de que sólo estamos escribiendo mismo patrón de código en todas las vistas y cada modelo de vista, el cambio que se convierte en un dolor enorme, y el mantenimiento es un dolor demasiado. MVVM es más adecuado para el desarrollo impulsado por pruebas, pero cuando se trata de escribir componentes extensibles, no son el mejor candidato.

---

WPF/Silverlight ya le permite separar el código y la interfaz de usuario muy bien, que de hecho ya ha diseñado jerarquía de clases muy simple que realiza la lógica de negocio y nos da todo lo que necesitamos. Ahora creamos todas las propiedades de comando basadas en ICommand como propiedades de dependencia de nuestras clases, que vinculamos dentro de UserControl y Templated Control.

ICommand en CodeBehind o Plantilla y Estilos en ResourceDictionary nos da casi todos los beneficios de lo que podemos obtener sobre MVVM.

Answer 5

Diferentes patrones tienen diferentes resistencias. La gente tiende a confundir el patrón con la implementación. Cómo se organiza o se accede a la lógica de negocios influye en qué patrón es más natural para una aplicación de entrega. Por lo tanto, aunque esta pregunta es acerca de WPF, puede resultar útil leer tres patrones utilizados para implementar la misma pantalla tres veces en cualquier marco.

A continuación se muestra un enlace a un artículo java que compara MVVM ("modelo de presentación") con MVP ("vista pasiva") y una implementación híbrida MVVMP/MVC ("controlador supervisor"). Creo que esto es relevante para esta pregunta ya que tiene una sección que tiene una comparación de los patrones.

Implementing event-driven GUI patterns using the ZK Java AJAX framework

Se señala la debilidad que Juan hace Gossman sino también va en comparar ambas fortalezas y debilidades con dos patrones alternativos.