Artigos .NET Design Patterns em .NET: o padrão MVP

Atenção: esse artigo tem um vídeo complementar. Clique e assista!

Demais posts desta série:
Design Patterns com .NET - Parte 2
Design Patterns com .NET - Parte 3
Artigo no estilo: Curso

Do que trata o artigo

O artigo mostra o design pattern MVP – ou Model (modelo de dados), View (interface do usuário) e Presenter (regras para a apresentação). No início é realizado um embasamento teórico e no final é realizado comparações com outros padrões como MVC e MVVM.

Para que serve

Os designs patterns ajudam os desenvolvedores a manterem um padrão de qualidade em suas criações tornando o processo de criação mais regular e organizado. Com o MVP o desenvolvimento de aplicações voltadas à interface com o usuário pode se beneficiar das vantagens de se separar lógica da apresentação e adicionar um terceiro elemento que torna possível reaproveitar as regras usadas para compor a apresentação dos dados em tipos de projetos distintos como uma aplicação Windows e outra em ASP.NET.

Model View Presenter

Uma preocupação constante dos desenvolvedores é reaproveitar o código. Com o surgimento de novas plataformas para suas aplicações como as executadas em browsers e em dispositivos móveis – torna-se muito difícil reusar as regras para apresentação dos dados em cada tipo de interface.

Com a evolução do Framework .NET evoluíram também os padrões para desenvolvimento. O MVP foi uma das propostas iniciais para promover a separação entre as camadas de apresentação, dados e regras de negócio sendo seguido por outros.

O MVP se baseia em três elementos, Model, para a definição da estrutura e comportamento dos dados e eventuais regras aplicadas nestes View – que faz a apresentação dos dados e Presenter – que serve como intermediário entre os dois elementos, estabelecendo alguns padrões para apresentação destes.

Com este design pattern o desenvolvedor deve ser capaz de criar uma aplicação que possa ter tipos de interface distintos como aplicações Windows Forms ou Web.

Uma das principais características é a divisão de parte da responsabilidade de compor a apresentação entre o Presenter e a View através do uso de interfaces. Desta forma, a View pode adaptar as definições do Presenter as suas características.

Não é só de flexibilidade e possibilidade de portar as aplicações para outras plataformas que vive o MVP. Há outras vantagens, por exemplo, aumentar a possibilidade de se executar testes automatizados (em se tratando de Test Driven Development ou TDD).

Antes de adotar um design pattern algumas considerações precisam ser feitas como o aumento significativo do tempo de desenvolvimento e dos passos necessários para se ter a aplicação funcionando. Estas considerações serão abordadas juntamente com um exemplo prático demonstrando o uso do MVP em uma aplicação.

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.

...
Quer ler esse conteúdo completo? Tenha acesso completo