Design Patterns: Model View Presenter - Revista .Net Magazine 93 - parte 1

Recentemente concluí uma série de três artigos nesta revista tratando de boas práticas em programação com C# e o Framework .NET. Dois destes eram sobre a separação da aplicação em camadas e isso tem uma boa razão: não dá mais para continuarmos criando programas com os paradigmas antigos.

A ideia de ver janelas onde você arrastava os controles visuais e escrevia pouco código está cada vez mais saindo de prática. Em vez disto, o foco está sendo aprender a escrever códigos e nem sinal de “janelinhas” com controles. A tendência agora é ter pouca coisa feita automaticamente pelas IDE´s como o Visual Studio.

O paradigma da época era desenvolver aplicações com aparência “profissional” da maneira mais rápida.

Não havia necessidade de se portar a aplicação para outras plataformas, mesmo porque, até a década de 1990 nem eram tantas as plataformas existentes. Logo, este problema não existia e nasceram então as linguagens “visuais” (sic).

Uma forte característica destas linguagens era a maneira como o código era escrito – geralmente respondendo a eventos disparados nos controles visuais. Este tipo de abordagem e padrão de desenvolvimento é chamado de code behind, ou seja, por trás de um design existe código sendo executado. Esta forma de escrever o código acaba agregando tanto regras relacionadas com os dados da aplicação como aquele necessário para controlar os aspectos de aparência da aplicação.

Também havia uma forte ligação dos controles com os dados. No Framework .NET você pode conectar diretamente os controles com os dados através das propriedades de data binding, definindo uma fonte para estes, configurando qual a propriedade está vinculada com o controle e também o comportamento em respostas a determinados eventos.

Dentro do contexto em que surgiram estas facilidades fazem todo o sentido. Quando há pouca necessidade de portabilidade da aplicação e esta é projetada para permanecer vinculada com uma plataforma, não será necessário se preocupar com sua arquitetura. Ainda que prover a separação entre as camadas lógicas do projeto seja uma boa prática, impacta diretamente na necessidade de manutenção e de evolução da aplicação, existem muitos casos onde esta prática não é adotada.

É importante observar que isto é uma parte da história e que dá um contexto para se entender como as linguagens de programação eram pensadas e quais os problemas que estas resolviam (ou pretendiam resolver).

Entretanto, atualmente o cenário é diferente e não é aceitável mais abordar o desenvolvimento de software com estes tipos de práticas.

Design Paterns

É comum que uma determinada aplicação tenha seus pontos de interação com o usuário em diversos tipos de plataformas e dispositivos, sendo o cenário mais conhecido aquele onde há uma interface baseada em um aplicativo desktop para os usuários acessarem de dentro da empresa e outra sendo executada no browser, para ser acessada de fora.

Ainda não existe uma forma de se escrever uma interface uma vez e executá-la em qualquer tipo de dispositivo ou plataforma, obtendo-se os mesmos resultados em termos de usabilidade e recursos. Muito embora, as interfaces baseadas em browsers tem entregado boa parte desta portabilidade, há muito que ser feito e provavelmente sempre vai haver um lapso entre os dispositivos, principalmente dada a sua natureza e forma de operação. Considere acessar uma aplicação ERP usando um smartphone, por exemplo.

Existem outros problemas além da portabilidade:

1.      Dificuldade em realizar testes automatizados, pois não é possível fazer simulações com a camada de apresentação.

2.      Quando for necessário fazer mudanças na camada de apresentação, também será necessário alterar o código já que diferentes elementos de interface possuem diferentes maneiras de manipular os eventos (event handlers).

Um design pattern reúne práticas e maneiras de se elaborar um projeto de software para promover soluções para estes e outros problemas.

Os mais usados são aqueles que possibilitam uma clara separação entre as camadas de um projeto e permitem sua rápida adaptação para novas necessidades.

Em se tratando de design patterns para o desenvolvimento de aplicações, o MVP se encaixa quando há necessidade de separar a estrutura dos dados, criar uma lógica para sua apresentação que seja consistente em diversos cenários e conectar isso tudo ao tipo de interface que está sendo usado.

Sobre o que se trata MVP

Atualmente este não é muito citado, tendo cedido espaço para outros design patterns como o MVC e o MVVM, especialmente em aplicações desenvolvidas com o Framework .NET. É um dos primeiros padrões a se estruturar dentro deste e terem as suas regras definidas. É ainda uma boa opção para ser feita quando se está pretendendo iniciar a adoção destes no desenvolvimento de aplicações e se tem ainda pouco conhecimento ou, como em muitos casos, se está bastante confuso sobre qual a alternativa adequada.

Também é muito fácil de ser entendido por programadores acostumados com o code behind, sendo que uma parte do código ainda vai presente na camada de apresentação (View). Este código, por outro lado, não se refere mais as regras vinculadas com os dados, mas, é exclusivamente usado para controlar aspectos particulares da camada de apresentação como manipular elementos visuais aplicando a estes as regras definidas na camada Presenter.

            O MVP separa as tarefas em três camadas:

1.      MODEL - responsável pelos dados e eventuais validações destes. O mais comum é ser representado pelas classes para estruturar os dados e determinar algumas de suas regras de negócio.

2.      VIEW - que faz a apresentação destes para o usuário. Vai ser definida usando elementos particulares de cada plataforma como páginas ASP.NET, formulários Windows, páginas WPF e assim por diante. Em MVP é comum que haja algum código necessário para responder a eventos dos elementos visuais e construção da interface."