Esse artigo irá explicar o que é e como utilizar o Caliburn.Micro, um framework de MVVM, Open Source, leve e compacto que pode ser utilizado para a construção de aplicações WPF, Silverlight ou Windows Phone 7.
Para que serve
MVVM é a sigla de Model-View-ViewModel, e remete a um padrão de separação da camada de apresentação de aplicações feitas com a tecnologia XAML. Com um único framework é possível aplicar o padrão MVVM em aplicações WPF, Silverlight e Windows Phone 7.
Em que situação o tema é útil
O Caliburn.Micro é uma ótima escolha para a construção de aplicações WPF, Silverlight e Windows Phone 7, onde se almeja a adoção do padrão MVVM. O uso do padrão MVVM permite uma real separação da camada de apresentação, de qualquer código que envolva regras de negócio da aplicação.
Caliburn.Micro
O Caliburn.Micro é um framework Open Source, que pode ser baixado gratuitamente no CodePlex (veja link para download na seção de Links). Com ele é possível implementar o padrão MVVM (Model-View-ViewModel) em aplicações baseadas em XAML. Isso significa que o Caliburn.Micro funciona para WPF, Silverlight e a versão Silverlight do Windows Phone 7, o que o torna ainda mais interessante, já que permite uma boa reutilização de código entre essas três plataformas. Como será demonstrado nas páginas seguintes deste artigo, um dos pontos mais interessantes do Caliburn.Micro é o fato de ele trabalhar com uma prática muito utilizada na orientação a objetos, chamada Convention-Over-Configuration. Este artigo irá mostrar como funciona o Caliburn.Micro para implementar o padrão MVVM em uma aplicação WPF.
São três os padrões mais conhecidos para construção de camadas de apresentação. O MVC, MVP e o MVVM. Cada uma dessas siglas representa um padrão de arquitetura, no que diz respeito à interface de usuário (camada de apresentação). O grande objetivo desses padrões é isolar ao máximo a camada de apresentação, no caso a letra V de todos eles, o View.
Aliás, esses padrões concordam apenas nas duas primeiras letras, o V (View) e o M (Model). A terceira parte, que é a que difere cada um deles, é também a que explica melhor como cada um deles funciona.
MVC (M – V – Controller)
MVC é o avô de todos esses padrões. Ele surgiu lá no começo da década de 80, mas se tornou muito popular na criação de aplicações Web. Sua dinâmica é simples, todas as requisições da aplicação são direcionadas para a camada Controller que acessa a camada Model para processar a tal requisição, e por fim exibe o resultado na camada View. Apesar de haver adaptações do MVC em aplicações ASP.NET Web Forms, o padrão MVC só passou a ser levado integralmente a sério na plataforma .NET com o surgimento do ASP.NET MVC. É a prova de que o padrão MVC inverte mesmo as coisas. Tanto que a Microsoft precisou criar uma versão diferente do ASP.NET, só para tratar desse assunto.
O ASP.NET MVC é totalmente diferente do ASP.NET Web Forms. Nele, todas as URLs apontam para métodos e classes de Controller, que se encarregam de processá-las e renderizar a View correta. No ASP.NET MVC não existem Postbacks, ViewStates e mais uma série de outras coisas que tornam ASP.NET Web Forms mais familiar para programadores acostumados com o Windows Forms.
MVP (M – V – Presenter)
Antes do surgimento do ASP.NET MVC, uma vertente dentro da comunidade .NET passou a procurar alternativas para não colocar muito código nos eventos de code-behind da camada de apresentação. Descobriu-se então que existia um padrão parecido com o MVC e que poderia facilmente ser implementado no ASP.NET Web Forms, ou até mesmo no Windows Forms. É o padrão MVP.
A camada Presenter faz o papel da camada Controller aqui, mas ela não recebe diretamente as requisições. No caso do ASP.NET WebForms, as URLs da aplicação continuam apontando paras as páginas aspx. A diferença é que nesse padrão é preciso criar uma interface que representa a View. Essa interface precisa conter todos os elementos importantes da View, principalmente aqueles que precisam acessar na camada Presenter.
A classe de code-behind das páginas e User Controls deverão implementar essas interfaces. A camada Presenter, por sua vez, irá se comunicar com a camada View também através dessas interfaces. Por fim, qualquer evento disparado na página deverá ser redirecionado para a classe Presenter.
Esse é o princípio básico, que consegue retirar do code-behind a maior parte do código, principalmente código que envolve algum tipo de lógica de negócio. Do ponto de vista de testabilidade é genial, pois é possível criar testes unitários para validar as classes da camada de apresentação.
Mas colocando essa questão de testabilidade de lado, esse tipo de implementação só traz complexidade adicional para o projeto, uma vez que precisa de uma interface para cada página da aplicação. É importante avaliar bem se compensa a adoção do padrão MVP, principalmente por conta desse nível de complexidade adicional.
MVVM (M – V – ViewModel)
O MVVM surgiu junto com o WPF e Silverlight para resolver o mesmo problema que os seus ancestrais resolvem. Aliás, o MVVM é baseado num padrão chamado Presentation Model criado por Martin Fowler. A ideia por trás desse padrão é representar o estado e comportamento da apresentação dos dados de forma independente dos controles utilizados na interface de usuário. Para isso ele introduz o conceito de uma classe que prepara os dados da camada de negócio para serem apresentados na interface. Além disso, como ele também abstrai o comportamento, essa camada de interface não mais possui lógica de negócio em si.
O MVVM define três figuras bem distintas, que compõem o seu próprio nome. A View representa a janela onde será exibida informação. Mas não apenas uma janela, o conceito aqui é mais abrangente. Uma view pode ser constituída de um conjunto de controles visuais ou, ser apenas um controle. O ViewModel nada mais é que uma classe que contém as ações e dados que uma View pode tomar e exibir, encapsulando sua lógica. Ele é responsável em preparar o Model para ser exibido pela View (observe como se assemelha ao Presentation Model). Model por sua vez são as classes de negócio envolvidas mais o que for necessário para a lógica do negócio.
A grande sacada do ViewModel está nos avançados recursos de
binding e commands que estão presentes no WPF e Silverlight. Graças a eles, a
comunicação entre o ViewModel e a View pode ser toda configurada no próprio
código XAML. O ViewModel obtém os dados do Model e notifica a View em eventuais
mudanças. A View por sua vez acessa os dados expostos pelo ViewModel através do
recurso de Binding. As ações que são tomadas, por exemplo, o que fazer no click
de um botão estão encapsuladas no ViewModel em objetos classificados de
Commands, ou comandos, que por sua vez estão também ligados à View por Binding.
( ...
