Conheça o framework MVVM Caliburn.Micro - Artigo Revista . Net Magazine 87

  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. (Figura 1).