Os padrões de arquitetura MVC, MVP e MVVM no Delphi

Este artigo fará um apanhado geral dos três padrões de arquitetura mais utilizados no desenvolvimento de software: MVC (Model-View-Controller), MVP (Model-View-Presenter) e MVVM (Model-View-ViewModel).

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

De que se trata o artigo

Este artigo fará um apanhado geral dos três padrões de arquitetura mais utilizados no desenvolvimento de software: MVC, MVP e MVVM. Serão vistos o significado de cada uma destas siglas e que tipo de problemas estes padrões visam resolver. Na medida em que forem apresentados, será elucidado em que tipo de tecnologia cada um melhor se encaixa. De antemão, pode-se citar como exemplo o padrão MVVM, que melhor se enquadra em aplicações WPF/Silverlight.

Em que situação o tema é útil

O que as siglas MVC, MVP e MVVM têm em comum é, além do fato de cada uma representar um padrão de arquitetura, todas têm como objetivo central isolar ao máximo a camada de apresentação de um sistema. Além disso, em termos de nomenclatura, todas coincidem em suas duas letras iniciais: M e V, que se referem às camadas Model (representação do domínio do sistema) e View (representação gráfica do modelo), respectivamente. Dessa forma, presume-se que o que varia entre estes padrões é o conceito em torno da outra letra restante. Todas estas constatações serão melhor detalhadas conforme o decorrer do artigo.

Os Padrões de Arquitetura MVC, MVP e MVVM

Em desenvolvimento de software, um padrão de arquitetura, a grosso modo, faz referência à forma de construção de um sistema. Para os desenvolvedores Delphi, principalmente depois do lançamento do Delphi Prism, que apresentou novas possibilidades devido à integração com o .NET Framework, três deste padrões já se tornaram uma constante em seu processo de desenvolvimento. São eles: MVC, MVP e MVVM, acrônimos de Model-View-Controller, Model-View-Presenter e Model-View-ViewModel, respectivamente. Em vista disso, o presente artigo visa apresentar uma explanação sobre cada um deles, com a intenção maior de atingir principalmente o público que está iniciando no desenvolvimento, seja com o Delphi tradicional ou Delphi Prism (em vista dos recentes artigos que esta revista tem apresentado sobre o assunto). Para este último, a abordagem se dará de forma mais teórica, já que em termos práticos, o uso destes padrões com o .NET Framework envolve, na maioria dos casos, outras tecnologias, frameworks e conceitos, que exigiriam artigos específicos sobre cada um. Dessa forma, a parte prática do artigo demonstrará a utilização de um destes padrões em um projeto Delphi Win32 tradicional. Esta escolha é justificada pelo fato de que para esse tipo de aplicação não é muito comum o uso destes padrões, devido a uma série de motivos. Dentre estes, pode-se citar a escassez de material sobre o assunto, que é o que o presente artigo visa sanar.

A construção de um software expõe aos desenvolvedores duas vertentes internas distintas, no que diz respeito às suas responsabilidades perante o produto final. Estas duas vertentes, ou partes, são conhecidas como modelo e visão. Um modelo é a representação do software mediante a resolução de um determinado problema, ou seja, é a visualização do sistema que se está construindo a fim de proporcionar um melhor entendimento. Já a visão é a porta de entrada para que o usuário possa interagir com este modelo, sem a necessidade de conhecimento de codificação para utilizá-lo. Outra função importante realizada por ela é a de representar visualmente os dados do modelo para o usuário. Conceitualmente falando, o ideal é manter estas duas partes do sistema desconectadas, como se fossem subsistemas. Dessa forma, uma visão poderia ser facilmente substituída a qualquer tempo, enquanto que um modelo bem definido poderia ser reutilizado em distintos projetos. Além disso, para que esta separação ocorra e se estabeleça, espera-se que não seja necessário um alto índice de trabalho, pois um processo muito trabalhoso poderia desencorajar a sua utilização.

Mesmo com os papéis bem definidos e dada a importância em manter as partes separadas, é comum encontrar situações em que o conceito é violado. Dessa forma, começa haver uma mescla entre as partes, ocasionando dependências desnecessárias e trazendo problemas futuros, imperceptíveis num primeiro momento, como prejudicar a manutenção de código e até mesmo a qualidade do produto final. Isto ocorre devido a fatores variados, sendo o principal deles a pressão por parte dos envolvidos (gerente e cliente), em vista do cumprimento de prazos.

SoC

SoC é o acrônimo de Separation of Concerns que, em português, poderia ser livremente traduzido como Separação de Interesses. Este termo, apesar de muitos não conhecerem, não se trata de um novo termo no jargão da ciência da computação. SoC já é um termo recorrente, cujo significado é simples: garantir que o código tenha um único e bem definido propósito (objetivo). Isso significa que o mesmo deve seguir uma linha de responsabilidades, evitando desvios e bifurcações. Esta separação de interesses é aplicável em todos os níveis de código, desde um simples método do sistema até as partes que o compõem.

O principal objetivo do SoC é limitar dependências e, nos casos em que seja imprescindível a existência de uma, esta dependência deve ser abstraída ao máximo. Isto se justifica pelo fato de que códigos demasiadamente interdependentes são mais difíceis de manter. Uma simples alteração pode significar a quebra de outras partes do sistema, em decorrência de uma possível dependência. Um exemplo mais grave é a existência de uma dependência de caráter cíclico, onde duas partes do sistema (duas classes, por exemplo) são mutuamente dependentes entre si, impedindo um possível crescimento natural de uma parte sem que este processo afete a outra parte."

[...] continue lendo...

Artigos relacionados