El modelo, vista, modelo de vista (patrón MVVM) se trata de guiarlo en cómo organizar y estructurar su código para escribir aplicaciones sostenibles, probables y extensibles.

Model - Simplemente contiene los datos y no tiene nada que ver con la lógica empresarial.

ViewModel - Actúa como enlace / conexión entre Model y ViewModel, y hace que las cosas se vean bonitas.

View - Simplemente contiene la fecha formateada y esencialmente delega todo al Modelo.

El beneficio clave es permitir una verdadera separación entre la Vista y el Modelo más allá de lograr la separación y la eficiencia que obtiene al tener eso. Lo que significa en términos reales es que cuando su modelo necesita cambiar, se puede cambiar fácilmente sin que la vista lo necesite y viceversa.

Hay tres cosas clave que se derivan de la aplicación de MVVM:

• Maintainability
• Testability
• Extensibility

• Algunas personas piensan que para una interfaz de usuario simple, MVVM puede ser una exageración.
• De manera similar, en casos más grandes, puede ser difícil diseñar ViewModel.
• La depuración sería un poco difícil cuando tenemos enlaces de datos complejos.

En general, el modelo es el más sencillo de entender. Es el modelo de datos del lado del cliente que admite las vistas en la aplicación.

• Está compuesto por objetos con propiedades y algunas variables para contener datos en memoria.

• Algunas de esas propiedades pueden hacer referencia a otros objetos del modelo y crear el gráfico de objetos que en su conjunto son los objetos del modelo.

• Los objetos de modelo deben generar notificaciones de cambio de propiedad, lo que en WPF significa enlace de datos.

• La última responsabilidad es la validación, que es opcional, pero puede incrustar la información de validación en los objetos del modelo utilizando las funciones de validación de enlace de datos de WPF a través de interfaces como INotifyDataErrorInfo / IDataErrorInfo.

El principal propósito y responsabilidades de las vistas es definir la estructura de lo que el usuario ve en la pantalla. La estructura contiene partes estáticas y dinámicas.

• Las partes estáticas son la jerarquía XAML que define los controles y el diseño de los controles de los que se compone una vista.

• La parte dinámica es como animaciones o cambios de estado que se definen como parte de la Vista.

• El objetivo principal de MVVM es que no haya ningún código detrás en la vista.

• A la vista, al menos necesita el constructor y una llamada para inicializar el componente.

• El código lógico de manejo de eventos, acción y manipulación de datos no debe estar en el código subyacente en View.

• También hay otros tipos de código que deben ir en el código detrás de cualquier código que se requiera para tener una referencia al elemento de la interfaz de usuario. Es un código de vista inherente.

• ViewModel es el punto principal de la aplicación MVVM. La responsabilidad principal de ViewModel es proporcionar datos a la vista, de modo que la vista pueda poner esos datos en la pantalla.

• También permite al usuario interactuar con los datos y cambiarlos.

• La otra responsabilidad clave de ViewModel es encapsular la lógica de interacción para una vista, pero eso no significa que toda la lógica de la aplicación deba ir a ViewModel.

• Debería poder manejar la secuencia apropiada de llamadas para que suceda lo correcto según el usuario o cualquier cambio en la vista.

• ViewModel también debe administrar cualquier lógica de navegación, como decidir cuándo es el momento de navegar a una vista diferente.

Hay dos formas de construir vistas. Puede utilizar cualquiera de ellos.

• Ver la primera construcción en XAML
• Ver la primera construcción en código subyacente

Una forma es simplemente agregar su ViewModel como un elemento anidado en el setter para la propiedad DataContext como se muestra en el siguiente código.

<UserControl.DataContext> 
   <viewModel:StudentViewModel/> 
</UserControl.DataContext>

Otra forma es que puede ver la primera construcción simplemente construyendo el modelo de vista usted mismo en el código detrás de su Vista configurando la propiedad DataContext allí con la instancia.

Normalmente, la propiedad DataContext se establece en el método de vista del constructor, pero también puede diferir la construcción hasta que se active el evento Load de la vista.

using System.Windows.Controls;

namespace MVVMDemo.Views { 
   /// <summary> 
      /// Interaction logic for StudentView.xaml 
   /// </summary> 
	
   public partial class StudentView : UserControl { 
      public StudentView() { 
         InitializeComponent(); 
         this.DataContext = new MVVMDemo.ViewModel.StudentViewModel(); 
      } 
   } 
}

La razón principal para construir ViewModel en código subyacente en lugar de XAML es que el constructor del modelo de vista toma parámetros, pero el análisis de XAML solo puede construir elementos si se define en el constructor predeterminado.

ViewModelLocator proporciona una forma estándar, coherente, declarativa y débilmente acoplada de hacer la primera construcción de la vista que automatiza el proceso de conectar ViewModel a la vista. A continuación se muestra el proceso de alto nivel de ViewModelLocator.

• Averigüe qué tipo de vista se está construyendo.
• Identifique el modelo de vista para ese tipo de vista en particular.
• Construya ese ViewModel.
• Establezca Views DataContext en ViewModel.

El enlace de datos es la característica clave que diferencia MVVM de otros patrones de separación de UI como MVC y MVP.

Los enlaces de datos pueden ser OneWay o TwoWay para que los datos fluyan hacia adelante y hacia atrás entre View y ViewModel.

Las plantillas de datos implícitas pueden seleccionar automáticamente una plantilla adecuada del diccionario de recursos actual para un elemento que utiliza el enlace de datos. Lo hacen en función del tipo de objeto de datos que se representa mediante el enlace de datos. Primero debe tener algún elemento que se vincule a un objeto de datos.

Hay dos actores principales, el invocador y el receptor en el patrón Command.

Invoker

Invoker es un fragmento de código que puede ejecutar cierta lógica imperativa. Normalmente, es un elemento de la interfaz de usuario con el que el usuario interactúa en el contexto de un marco de interfaz de usuario. Pero podría ser solo otro fragmento de código lógico en otro lugar de la aplicación.

Receiver

Receptor es la lógica que está destinada a ejecutarse cuando el invocador dispara. En el contexto de MVVM, el receptor suele ser un método en su ViewModel que debe llamarse.

Entre el invocador y el receptor, hay una capa de obstrucción que no permite que el invocador y el receptor se conozcan explícitamente. Esto generalmente se representa como una abstracción de interfaz expuesta al invocador y una implementación concreta de esa interfaz es capaz de llamar al receptor.

No, si el fragmento de contenido solo proporciona la estructura para representar algo en la pantalla y no admite ninguna entrada o manipulación por parte del usuario para ese contenido. Puede que no necesite un ViewModel separado, pero podría ser solo un fragmento XAML que se procesa según las propiedades expuestas por el ViewModel principal.

Cuando su aplicación comience a aceptar la entrada de datos de los usuarios finales, debe considerar validar esa entrada. Para asegurarse de que cumpla con sus requisitos generales.

Puede usar las siguientes formas de expresar la validación que son compatibles con el enlace de datos de WPF:

• Se establece el lanzamiento de excepciones en una propiedad.
• Implementación de la interfaz IDataErrorInfo.
• Implementando INotifyDataErrorInfo.
• Utilice las reglas de validación de WPF.

La inversión de control (IoC) y la inyección de dependencia son dos patrones de diseño que están estrechamente relacionados y el contenedor es básicamente un fragmento de código de infraestructura que realiza ambos patrones por usted. El patrón de IoC se trata de delegar la responsabilidad de la construcción y el patrón de inyección de dependencia se trata de proporcionar dependencias a un objeto que ya se ha construido.

Un evento es una construcción de programación que reacciona a un cambio de estado, notificando cualquier punto final que se haya registrado para notificación. Principalmente, los eventos se utilizan para informar la entrada de un usuario a través del mouse y el teclado, pero su utilidad no se limita a eso. Siempre que se detecta un cambio de estado, tal vez cuando se ha cargado o inicializado un objeto, se puede disparar un evento para alertar a los terceros interesados.