Tengo algunas preguntas sobre el patrón MVVM

Mi nombre es Jesús de España, soy un desarrollador de .NET y acabo de descubrir esta gran web hace unos días.

Tengo algunas preguntas sobre el patrón MVVM y me alegraré si puede responderlas.
Comencé a usar WPF hace tres meses y aprendí el patrón MVP.
MVP es muy bueno porque puedes estructurar la aplicación muy bien.

Comencé a ver MVVM en todas partes, pero todos están usando el patrón por su propio método.
Todos los bloggers hablan de MVVM en los blogs de WPF, pero cada implementación es distinta.

Ahora estoy enfocado en las implementaciones que usan el kit de herramientas MVVM en CodePlex, pero tengo preguntas y no puedo encontrar mucha información.

Creo que MVVM es una variación de MVP.
Con MVP cada vista tiene un presentador que hace el trabajo de la vista.
En MVVM es lo mismo pero usar comandos siempre que pueda.

También vi que si necesitas un evento, es como con MVP; delegar el evento al presentador / modelo de vista, es decir, si no es un trabajo para la vista (como actualizar la interfaz de usuario).

Por otro lado, el modelo de vista no tiene una referencia de vista, por lo que tengo que jugar más duro con los enlaces de datos.
Tienes que usar los Comandos Delegados (que son lo mismo que RelayCommands, ¿verdad?).

Uhm … más preguntas … ¿Es seguro usar el mismo modelo de vista con dos vistas / controles de usuario?

Oh … Me encontré con un problema ayer cuando estaba jugando MVVM.
CommandReference una CommandReference de mi comando para el enlace de clave y CanExecuted esta referencia a la propiedad de comando de mi botón, bueno, CanExecuted funcionó la primera vez, pero no actualizó la propiedad IsEnabled cuando CanExecuted era verdadero. Lo arreglé enlazando el comando directamente al botón y no usando la referencia. La pregunta es: ¿por qué un código está vinculando la referencia a los objetos y por qué otro código está enlazando el comando directamente?

¿Qué cosas relacionadas con MVVM debo aprender? (Vi algo llamado comportamiento adjunto ayer, pero no sé qué es eso).

Estoy reescribiendo una aplicación de notas que desarrollé usando MVP pero ahora con MVVM. Reemplazaré los eventos con comandos (usando DelegateCommand), eliminaré las referencias de vistas en el modelo de vista y creo que eso es todo porque los ejemplos que vi de MVVM son muy parecidos a MVP.

Bueno, apreciaré si me señala todos los malentendidos que tengo con este patrón.

Gracias y en el futuro ayudaré a los próximos novatos de MVVM 🙂

Wow, voy a tratar de responder la mayor cantidad de preguntas, que no involucren una tecnología o marco específico, como sea posible … perdón si me olvido de algunas (los puntos de bala ayudarían)

  • MVVM no es necesariamente una variación de MVP. MVP en sí mismo es un término ambiguo y cargado. Martin Fowler lo hizo justicia al dividirlo en dos patrones . MVVM es independiente, pero comparte algunos conceptos con los patrones MVP. Como todos los patrones de UI, busca separar la lógica de vista de la lógica de negocios tanto como sea posible. Lo que hace MVVM que es diferente de MVP es que crea un modelo con el único propósito de la presentación (o un modelo de presentación ). Esto es diferente a cómo los patrones MVP resuelven el problema de separación.
    • Vista pasiva : con la vista pasiva, la vista nunca ve el modelo.
    • Controlador supervisor : MVVM está mucho más cerca del patrón del controlador supervisor que de la vista pasiva. La única diferencia real aquí podría ser que la MVVM crea explícitamente un modelo solo para la vista (de ahí el término “Ver modelo”)
  • El ViewModel no tiene una referencia a la vista, ya que sirve como modelo para los datos de la vista. Esta es una abstracción apropiada. Si también hiciera referencia a la vista, tendría una dependencia bidireccional que crearía un acoplamiento adicional. Además, el ViewModel en sí no tiene una razón real para estar al tanto de la Vista. Su único trabajo es abstraer el modelo (el modelo de negocio real) de la vista.
  • DelegateCommands vs. RelayCommands: creo que está obteniendo tecnología específica aquí, así que realmente no puedo responder a esa pregunta bien.
  • No debe diseñar un ViewModel para más de una vista. Esto solo crea coplexidad ya que si cambia una vista, tendrá que investigar qué ViewModels podrían verse afectados y cambiarlos. Esto podría conducir a un efecto de cascada. Su comportamiento debe estar en el modelo de negocio, no en el ViewModel, por lo que ViewModel solo necesita contener la traducción y la lógica de manejo de eventos.
  • Sin embargo, sería una buena idea tener una proporción de 1: 1 de ViewModel a UserControl, ya que se supone que UserControls puede actuar como unidades autónomas en su pantalla.
  • En cuanto a las otras preguntas específicas de tecnología, lo siento, no tengo respuesta. Sin embargo, puedo sugerirle que lea atentamente los enlaces que incluí para la Vista pasiva , el Controlador supervisor y el Modelo de presentación . Proporcionan cierto contexto a los patrones de UI, y son tecnológicamente neutrales.

Es importante tener en cuenta que, si bien MVVM es adecuado para resolver los problemas planteados por la adopción de WPF, no es un patrón específico de la tecnología. Si te sumerges demasiado en una implementación específica sin entender la filosofía subyacente, podrías cometer algunos errores muy grandes desde el principio, y solo descubrirlos después de que sea demasiado tarde. Desafortunadamente, MVVM no es un patrón bien documentado, y tienes razón cuando afirmaste que cada uno tiene su propia idea de lo que es.

No es un patrón revolucionario (ha existido durante años con diferentes nombres), pero el enlace de datos de WPF lo convierte en una solución viable ahora, y por lo tanto está disfrutando de una nueva popularidad. Es un buen patrón, pero no es doctrine. Enfoque cada “dictado” con el que se enfrenta con la cantidad apropiada de escepticismo.

EDITAR

@micahtan tiene razón cuando afirma que el enlace de datos es una pieza muy importante en WPF. Declaré que el enlace de datos de WPF habilita la solución MVVM, pero el enlace en sí mismo es muy poderoso, por lo que la adopción de MVVM está creciendo más rápido que la literatura que lo rodea.

No tienes que usar RelayCommand. Todo lo que necesita hacer es implementar la interfaz ICommand en un objeto. En el marco de SoapBox Core , definí una interfaz llamada ICommandControl y todos los botones ViewModels, etc. implementan eso. También hay una clase AbstractCommandControl que puede derivar para implementarla.