.net - tutorial - ¿Siempre usa MVVM en una aplicación WPF, o son patrones alternativos todavía prácticos/útiles?

wpf vs windows forms

Question

En la página 374 del libro Microsoft .NET Architecting Applications para la empresa , hay un cuadro con la evolución de los patrones para la capa de presentación y su impacto en las plataformas (figura 7-14).

Además de mostrar la evolución del patrón MVC original, a las variantes más modernas, esa tabla también muestra que los siguientes patrones modernos pueden aplicarse a las siguientes tecnologías:

1. Modelo 2 (MVC)
   • Solo web
2. Vista pasiva (MVP)
   • Web
   • WinForms
   • WPF
3. Controlador Supervisor (MVP)
   • Web
   • WinForms
   • WPF
4. MVVM (Modelo de presentación)
   • Sólo WPF

Nota: Otro patrón reciente de interés últimamente que no se encuentra en esa tabla es Presenter First (MVP), que se pensó que sería más complaciente con TDD.

Por lo que entiendo si uno se desarrolla con WPF, entonces el patrón MVVM es la elección de facto (algo así como Model2 es para el desarrollo web). Dicho esto, parece que nada impide que se use la vista pasiva , el supervisor supervisor o el presentador primero en una aplicación WPF. Un enfoque de este tipo resultaría en una aplicación a la que realmente no le importa si la interfaz es WPF, WinForms o la Web. Parece que estas variantes de MVP permiten más flexibilidad.

Sin embargo, ¿el objetivo de la flexibilidad independiente de la plataforma UI (que podría no ser necesaria) tiene el costo de hacer que el desarrollo de WPF sea mucho más difícil y perder una parte de las características / potencia que ofrece WPF? ¿Tanto que los costos superan a los beneficios?

En otras palabras, ¿es MVVM tan bueno que uno no debería considerar otras alternativas en las aplicaciones WPF?

Answer 1

De acuerdo con la documentación incluida en MVVM para WPF (página 2 de la introducción general)

Los orígenes de este patrón son oscuros, pero probablemente se deriven del patrón Smalltalk ApplicationModel, al igual que el patrón PresentationModel descrito por Martin Fowler. Fue adaptado para uso de WPF por el equipo de Expression ya que desarrollaron la versión 1 de Blend. Sin los aspectos específicos de WPF, el patrón Model-View-ViewModel es idéntico a PresentationModel.

Al ir al sitio web de Martin''s Fowler y buscar el Modelo de presentación , tenemos este

En comparación con la Vista pasiva y el Controlador supervisor, el Modelo de presentación le permite escribir una lógica que es completamente independiente de las vistas utilizadas para la visualización. Tampoco es necesario confiar en la vista para almacenar el estado. El inconveniente es que necesita un mecanismo de sincronización entre el modelo de presentación y la vista. Esta sincronización puede ser muy simple, pero es necesaria. La Presentación Separada requiere mucho menos sincronización y la Vista Pasiva no necesita ninguna.

Para mi propia aplicación CAD-CAM para corte de metales, uso la vista pasiva . Las razones de esto son

1. Para facilitar las pruebas al tener objetos simulados que implementan la vista, permita que la gran mayoría de las funciones de mi software se prueben automáticamente
2. Para reutilizar no solo el modelo principal, sino también las diferentes vistas para los tipos relacionados de software de corte de metal.
3. Para documentar claramente la interacción entre las vistas y el modelo.
4. Para destruir cualquier dependencia del kit de herramientas GUI ya que este software ha sido un desarrollo continuo desde 1985 y se han observado varios cambios importantes en las herramientas subyacentes, las API e incluso el lenguaje en sí.

Las inquietudes de los tres primeros pueden manejarse con el patrón MVVM, Modelo de presentación, Supervisor del controlador. Pero solo la Vista Pasiva aborda el # 4.

Como afirma Martin Fowler, solo la vista pasiva no requiere ningún método de sincronización. MVVM es una implementación del modelo de presentación para WPF. Depende de la interfaz XAML para vincular el estado de vista ubicado en el Modelo de vista con la Vista en sí. Entonces, si más adelante cambia la interfaz de usuario o sus API, también se cambiará su modelo de vista.

Por el contrario, la vista pasiva solo requiere que los nuevos elementos de la interfaz de usuario implementen la interfaz de vista. No importa a qué se conectan realmente también, ya que el formulario o los controles que implementan responden correctamente.

Pero el precio es que tiene un paso adicional al implementar nuevos elementos de una vista. Debe decidir cómo se presentarán al presentador y en qué nivel de abstracción. Es suficiente que se anule en algunos proyectos o en algunos tipos de IU como cuadros de diálogo.

La respuesta corta a su pregunta acerca de que MVVM es EL CAMINO para WPF, la respuesta es no, no lo es. Es una herramienta que debe ser considerada a la luz de los otros problemas que rodean el desarrollo de su aplicación.

Answer 2

He estado trabajando en la implementación de MVP con una aplicación MVPM WP7 (Silverlight) durante los últimos dos meses. Creo que he logrado encontrar una buena solución de trabajo que aprovecha lo mejor de ambos mundos. El inconveniente es que hay un poco de código de "andamiaje". La ventaja es un marco MVP donde los niveles de Modelo y Presentador deben ser reutilizables entre WP7, WM y Android (dado MonoDroid).

Utilicé MVP-VM como se describe aquí - http://aviadezra.blogspot.com/2009/08/mvp-mvvm-winforms-data-binding.html - como base para mi diseño.

El modelo es el modelo y no debería necesitar ninguna aclaración. Contiene las clases de datos, la lógica de negocios y los servicios, y no hace referencia a nada específico de la interfaz de usuario.

Las interfaces de presentadores y vista siguen el patrón de vista pasiva.

Las interfaces de visualización se componen principalmente de eventos, algunas propiedades y algunos métodos. Todo lo que pasa entre el presentador y la vista no es específico de la interfaz de usuario.

Las implementaciones de vista son una tríada de PhoneApplicationPage (o formulario WPF), PageViewModel y ViewFacade.

ViewFacade es lo que realmente implementa la interfaz View. Es responsable de coordinar la página y el modelo de vista. Infla eventos de la Página, hace que la mayoría de ellos se activen de forma asíncrona, lo que el Presentador detecta. También transforma cualquier parámetro de evento específico de UI en parámetros no UI. Todo lo que venga del presentador a ViewFacade se verifica en cuanto a seguridad de subprocesos de la interfaz de usuario y se invoca correctamente. Las propiedades suelen ser datos y se pasan a ViewModel.

Mantener la implementación de la interfaz de Vista (ViewFacade) separada de la clase de IU real (Página, Formulario, etc.) ayuda a mantener las responsabilidades distintas entre las clases de la tríada de Vista. Por ejemplo, uno de los propósitos principales de ViewFacade es ser la capa donde ocurre la sincronización de hilos.

La página / ViewModel se realiza principalmente como lo haría normalmente, sin embargo, los comandos son eventos que se propagan a través del ViewFacade al presentador.

Ventajas

Diseño y reutilización de MVP entre plataformas.

Fácil enlace de datos con MVVM.

OMI, MVP es más lógico y más fácil de conceptualizar.

Desventajas

Duplicación de código entre eventos de página y eventos de ViewFacade, propiedades de ViewModel y propiedades de ViewFacade.

Los casos simples pueden tener mucho más código del que es realmente necesario.

Al final, debe preguntarse si vale la pena el esfuerzo adicional de MVP. ¿Es más importante un ciclo de desarrollo más rápido que la reutilización en las plataformas y la capacidad de prueba mejorada?

Answer 3

La respuesta de @RS Conley está dando un enfoque muy amplio al tema, y ​​estoy de acuerdo con la mayoría. Lo único que pienso diferente está en la línea de fondo.

MVVM es LA arquitectura para el 95% de las aplicaciones en WPF.

Elegir cualquier otra arquitectura es una solución a algo que es menos que lo mejor que puede obtener. En la situación de RS Conley, la vista pasiva puede ser la mejor manera de proceder, pero está lejos de ser el caso normal.

Como una forma de entender cómo MVVM es mejor, veamos qué está perdiendo cuando adopta el enfoque de PassiveView.

Mantenibilidad

En la vista pasiva, ViewModel sabe acerca de la vista IV, lo que significa que no se mantiene el principio de responsabilidad única (SRP, por sus siglas en inglés). El Controlador en PassiveView interactúa directamente tanto con el Modelo como con la Vista, ¡y por lo tanto está haciendo dos cosas completamente diferentes! .

Bajo MVVM, el ViewModel, que es el corazón de la aplicación, solo tiene una preocupación, que es contener el estado y la lógica de la aplicación. La capacidad de mantenimiento de dicho código es realmente superior a PassiveView, MVP o MVC treamendously.

Es cierto que PassiveView es mejor cuando se trata de pruebas de cobertura automatizadas, pero en mi humilde opinión, el buen mantenimiento del código es mucho más importante. La capacidad de prueba lo ayuda a asegurarse de no romper su código, mientras que la capacidad de mantenimiento lo ayuda a comenzar a crear código problemático.

Cuando se trata de mantenimiento, MVVM y PresentationModel son una evolución de las arquitecturas de UI anteriores, y eso se debe a que el principio de SRP se mantiene de manera muy estricta. Escribe suficiente código en MVVM y verás lo que quiero decir.

Mezclabilidad

Otra característica donde MVVM es realmente fuerte es la capacidad de mezcla. Dado que todo el estado de la aplicación se conserva dentro de ViewModel, es fácil falsificar datos para el tiempo de diseño, lo que permite un gran aumento de la productividad. Esto es imposible de crear en PassiveView, MVP o MVC, porque en todas esas arquitecturas el controlador tiene que colocar activamente los datos dentro de la vista. En MVVM, los datos simplemente "saltan" a la Vista y, por lo tanto, se pueden burlar.

Probabilidad

Este es de hecho un lugar donde PassiveView es superior a MVVM. Si el 100% de cobertura de UI de Pruebas Unitarias es crucial para usted, entonces es un gran problema. Sin embargo, en la mayoría de las situaciones, la cobertura que MVVM le permite es más que suficiente, y generalmente agregará otro nivel de prueba utilizando las pruebas de UI regulares (que terminaría haciendo en PassiveView también por cierto).

Creo que la capacidad de prueba es la menos importante de las tres características. Ordenados por importancia, es la capacidad de mantenimiento, la integridad y la capacidad de prueba.

¿Dónde no es MVVM la elección correcta?

He participado en ~ 15 proyectos WPF y Silverlight el año pasado, todos los cuales MVVM encaja perfectamente. Creo que en lugares donde la lógica de presentación es extremadamente grande, como en los juegos, MVVM podría no ser la elección correcta. Aparte de los juegos, realmente no puedo pensar en una categoría de aplicación que no vaya mejor con MVVM, aparte de situaciones especiales como la mencionada RS Conley.