MVVM - Introdução

A maneira bem ordenada e talvez a mais reutilizável de organizar seu código é usar o padrão 'MVVM'. oModel, View, ViewModel (MVVM pattern) tem como objetivo orientar você sobre como organizar e estruturar seu código para escrever aplicativos que podem ser mantidos, testados e extensíveis.

Model - Ele simplesmente contém os dados e não tem nada a ver com qualquer lógica de negócios.

ViewModel - Ele atua como o link / conexão entre o Modelo e a Visualização e torna as coisas bonitas.

View - Ele simplesmente mantém os dados formatados e essencialmente delega tudo ao modelo.

Apresentação Separada

Para evitar os problemas causados ​​ao colocar a lógica do aplicativo em code-behind ou XAML, é melhor usar uma técnica conhecida como apresentação separada. Estamos tentando evitar isso, onde teremos XAML e code-behind com o mínimo necessário para trabalhar diretamente com objetos de interface do usuário. As classes de interface do usuário também contêm código para comportamentos de interação complexos, lógica de aplicativo e tudo o mais, conforme mostrado na figura a seguir no lado esquerdo.

• Com a apresentação separada, a classe de interface do usuário é muito mais simples. Ele tem o XAML, é claro, mas o código por trás dele faz o mínimo possível.

• A lógica do aplicativo pertence a uma classe separada, que geralmente é chamada de modelo.

• No entanto, esta não é toda a história. Se você parar por aqui, provavelmente repetirá um erro muito comum que o levará ao caminho da insanidade de vinculação de dados.

• Muitos desenvolvedores tentam usar vinculação de dados para conectar elementos no XAML diretamente a propriedades no modelo.

• Agora, às vezes isso pode estar bem, mas muitas vezes não é. O problema é que o modelo se preocupa inteiramente com o que o aplicativo faz, e não com a forma como o usuário interage com o aplicativo.

• A maneira como você apresenta os dados costuma ser um pouco diferente de como são estruturados internamente.

• Além disso, a maioria das interfaces de usuário tem algum estado que não pertence ao modelo de aplicativo.

• Por exemplo, se sua interface de usuário usa arrastar e soltar, algo precisa manter o controle de coisas como onde o item que está sendo arrastado está agora, como sua aparência deve mudar conforme ele se move sobre possíveis alvos para soltar e como esses alvos também podem mudar conforme o item é arrastado sobre eles.

• Esse tipo de estado pode se tornar surpreendentemente complexo e precisa ser totalmente testado.

• Na prática, você normalmente quer alguma outra aula entre a interface do usuário e o modelo. Isso tem duas funções importantes.

  • Primeiro, ele adapta o modelo do seu aplicativo para uma visão específica da interface do usuário.

  • Em segundo lugar, é onde reside qualquer lógica de interação não trivial e, com isso, quero dizer o código necessário para que sua interface de usuário se comporte da maneira que você deseja.