MVVM - Introducción
La forma bien ordenada y quizás la más reutilizable de organizar su código es usar el patrón 'MVVM'. losModel, View, ViewModel (MVVM pattern) 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 el modelo y la vista y hace que las cosas se vean bonitas.
View - Simplemente contiene los datos formateados y esencialmente delega todo al modelo.
Presentación separada
Para evitar los problemas causados por poner la lógica de la aplicación en código subyacente o XAML, es mejor usar una técnica conocida como presentación separada. Estamos tratando de evitar esto, donde tendremos XAML y código subyacente con el mínimo requerido para trabajar con objetos de la interfaz de usuario directamente. Las clases de interfaz de usuario también contienen código para comportamientos de interacción complejos, lógica de aplicación y todo lo demás, como se muestra en la siguiente figura en el lado izquierdo.
Con una presentación separada, la clase de interfaz de usuario es mucho más simple. Tiene el XAML, por supuesto, pero el código detrás hace tan poco como es práctico.
La lógica de la aplicación pertenece a una clase separada, que a menudo se denomina modelo.
Sin embargo, esta no es toda la historia. Si se detiene aquí, es probable que repita un error muy común que lo llevará por el camino de la locura de vinculación de datos.
Muchos desarrolladores intentan usar el enlace de datos para conectar elementos en XAML directamente a propiedades en el modelo.
Ahora bien, a veces esto puede estar bien, pero a menudo no lo es. El problema es que el modelo se preocupa por completo de lo que hace la aplicación y no de cómo interactúa el usuario con la aplicación.
La forma en que presenta los datos a menudo es algo diferente de cómo están estructurados internamente.
Además, la mayoría de las interfaces de usuario tienen algún estado que no pertenece al modelo de aplicación.
Por ejemplo, si su interfaz de usuario utiliza arrastrar y soltar, algo debe realizar un seguimiento de cosas como dónde se encuentra el elemento que se está arrastrando en este momento, cómo debería cambiar su apariencia a medida que se mueve sobre posibles destinos de colocación y cómo esos destinos de colocación también podrían cambiar a medida que el elemento se arrastra sobre ellos.
Este tipo de estado puede volverse sorprendentemente complejo y debe ser probado a fondo.
En la práctica, normalmente desea que otra clase se ubique entre la interfaz de usuario y el modelo. Esto tiene dos roles importantes.
Primero, adapta su modelo de aplicación para una vista de interfaz de usuario en particular.
En segundo lugar, es donde vive cualquier lógica de interacción no trivial, y con eso, me refiero al código necesario para que su interfaz de usuario se comporte de la manera que desee.