Olá pessoal!
Após um intervalo de tempo bem grande (suficiente para terminar minha graduação e descansar um pouco), voltei a postar aqui no blog :-). E com prazer, pois neste post voltarei a tratar um assunto que não mexia a algum tempo: Silverlight.
Porém, o foco não é falar sobre as novidades do Silverlight 4, nem como podemos desenvolver aplicações financeiras ou de entretenimento para Windows Phone 7 utilizando essa plataforma RIA. Afinal, para isso recomendo os vídeos do MIX 2010 (como este overview) ou o excelente material do Channel 9.
Falarei sobre um padrão arquitetural de apresentação bem específico ao WPF e Silverlight: o MVVM (Model-View-ViewModel).
O MVVM nasceu da necessidade de separarmos as responsabilidades na camada de apresentação, facilitando a vida da equipe de design gráfico com a redução de impactos nas alterações das Views e aumentando a testabilidade do sistema, por possuir naturalmente o domínio desacoplado da lógica de visualização.
O modelo de desenvolvimento de RIAs proposto pela Microsoft compreende na colaboração entre dois tipos de equipe: designers e desenvolvedores. Com o advento do Expression Blend e das APIs de desenvolvimento WPF e Silverlight para .NET 3, 3.5 e 4, isto passou a ser possível de uma forma bem menos traumática e integrada. Mas o mercado exigia mais.
E aí entra o MVVM. Pense na idéia de isolar os designs das telas de qualquer fator de infra-estrutura, comunicação externa ou alguma dependência que impeça a continuidade dos layouts. Imagine que enquanto essas telas são feitas sua equipe de desenvolvimento pode projetar e desenvolver o domínio do sistema, onde a coisa pega e geralmente mora toda a complexidade do seu software, linhas e mais linhas de LoB, controle transacional orientado a aspectos, specifications, DSLs e toda aquela tropa. Você não vai querer isso no meio dos seus bindings, conversões e validações do WPF, vai?
Some isso ao fato de você poder testar seu domínio sem se preocupar com escrever longos testes de integração e UI automation, que permeiam desde os code-behinds de seus XAML até suas classes de mapeamento relacional.
A idéia aqui é testar “a cola entre os dois mundos”, que por sinal se chama “ViewModel” (mundialmente conhecida e batizada pelo Fowler como Presentation Model). MVVM é só um nome bacana para aplicações que trabalham com marcações XAML. Tudo começou neste post do John Grossman, lá no início da era WPF & Silverlight.
Para falar a verdade, o MVVM se distingue do resto da família (MVC, MVP, Presentation Model, Mxxx …) por fatores tecnológicos bem específicos, como:
- Uso dos DataBinds bi-direcionais e a interface INotifyPropertyChanged (do namespace System.ComponentModel) para disparar alterações nos modelos de visualização (a.k.a ViewModels).
- Conversão e formatação de valores através dos Converters (interface IValueConverter no System.Windows.Data).
- Validação de valores integradas ao modelo de DataBinding da plataforma (ValidatesOnDataErrors = True) e ao Validation Application Block (da Enterprise Library).
- Modelo de eventos utilizando a interface ICommand do namespace System.Windows.Input.
Para mais informações, o Channel 9 possui um vídeo bem curto e interessante sobre o funcionamento do MVVM, mas vou comentar os elementos do MVVM apresentando um framework auxiliar. Por falar em frameworks, existe um link interessante com uma lista dos principais toolkits que ajudam na implementação do MVVM. Praticamente todo desenvolvedor que trabalha com este padrão possui uma coleção de classes bases, interfaces e templates para geração de código que aumentam o reuso e produtividade.
Nos exemplos que colocarei aqui, utilizarei o MVVM Light Toolkit, ele é bem simples, de fácil instalação (basta descompactar os arquivos na pasta de templates do Visual Studio) é compatível com as últimas versões do Silverlight e WPF e até onde usei, não me causou incomodações.
Após descompactar o template, crie um projeto Silverlight com o template do Light Toolkit:
Na figura acima, o projeto da esquerda contém exatamente a estrutura que o MVVM Light Toolkit gera ao criarmos um projeto. Já a figura da direita é a estrutura final de um cenário de Master-Detail utilizando MVVM, que será mostrado na parte final desta série.
Em uma leitura top-down do solution-explorer, ao expandirmos a pasta “References” veremos dois binários do Light Toolkit: Galasoft.MvvmLight.dll e Galasoft.MvvmLight.Extras.dll. São as bibliotecas que contém suporte para operações básicas de ViewModels, comandos genéricos, thread-handling, janelas de mensagens, notificações de propriedades alteradas, etc.
- Models: O template gera uma pasta chamada “Models“, como o ASP.NET MVC Framework e o Ruby on Rails, onde geralmente são criadas classes que representam os limites do domínio da aplicação, como Application Services [1][2], objetos que realizam orquestração de fluxos (e.g: Transaction Scripts), classes de acesso relacional ou até mesmo entidades de negócio. A título de simplicidade, no exemplo do Master-Detail coloquei as entidades (Jogador e TimeFutebol) direto nesta pasta, mas o comum é que isto seja feito em assemblies separados.
- Skins: pasta para colocarmos os “Skins” da aplicação, que básicamente são arquivos XAML com dicionários de recursos gráficos (e.g: animações, estilos, fontes, imagens) que podem ser compartilhados por toda aplicação.
- ViewModel: onde grande parte da mágica acontece. Nesta pasta vão todas as “classes-cola” entre o mundo de design (Views) e desenvolvimento (Models). São abstrações que encapsulam todas informações e comportamentos que as Views necessitam e possuem, servindo como DataContext das mesmas. É nas ViewModels que iremos encontrar tratadores de comandos, propriedades auto-calculadas das Views (e.g: o título de uma aba de emails não lidos), propriedades utilizadas para fazer binding na tela (e.g: lista de clientes para ser exibida em uma ComboBox), estados de controles, etc. Por possuírem alto nível de acoplamento com outras camadas (View e Model) quase sempre as ViewModels são projetadas com interfaces e injetadas por containers de IoC. O MVVM LightToolkit resolve a inversão de controle nas ViewModels utilizando Service Locator, que é o motivo da classe ViewModelLocator ser criada junto com o projeto.
- ViewModelLocator (opcional): implementação do Service Locator pattern. Conhece e gerencia o ciclo de vida de todas ViewModels do sistema. É declarada nos recursos da aplicação (dentro do App.xaml), para que todas as telas (Views) possam referenciá-la e obter o contexto dos dados. Uma forma bem simples de simular um container de implementações :-).
O template ainda cria uma MainPage.xaml referenciando sua respectiva ViewModel, cujos bindings, validadores e conversores veremos no próximo post, com exemplos de código e mais explicações sobre o modelo de interação do MVVM :-).
Referências:
[1] http://dddsample.sourceforge.net/characterization.html
[2] http://martinfowler.com/eaaCatalog/serviceLayer.html
[]z
Life's too short for bad software 