Artigos Delphi Padrão MVVM (Model View ViewModel) no Delphi
De que se trata o artigo

Este artigo tem por finalidade destacar a importância de se organizar uma aplicação em camadas lógicas, como conseguir isso separando a interface visual de sua lógica ao fazer uso do padrão MVVM e como ele pode ser aplicado em Delphi através do Framework DSharp. São abordados conceitos como DataBinding, separação de camadas e as vantagens que essa separação traz.

Em que situação o tema é útil

Este tema é utilizado para se organizar o código fonte de uma aplicação, separando as funcionalidades existentes em camadas lógicas. Um exemplo do que deve ser separado é a camada visual e a camada de negócios, que uma vez independentes uma da outro, permitem a aplicação de outra boa prática, o uso de testes automatizados.

MVVM no Delphi

Desde o Delphi 2010 vários recursos internos foram acrescidos à linguagem Delphi. Muitos deles localizados na parte de RTTI, ou introspecção de informações. Com isso a linguagem foi ficando poderosa o suficiente para facilitar o desenvolvimento de Frameworks que hoje auxiliam na aplicação das mais diversas boas práticas da orientação a objetos. A divisão de responsabilidades é uma dessas. Porque a camada de interface precisa estar tão ligada à camada de negócios? O ideal é que ela somente apresente os dados. Conseguir isso não era fácil, contudo temos agora o DSharp, um Framework que implementa o padrão de separação visual MVVM. O ponto chave desse padrão é a utilização do recurso chamado DataBinding, ou ligação de dados, para propiciar essa separação. É exatamente isso que o DSharp traz e que vamos explorar neste artigo, construindo exemplos e discutindo a teoria.

A separação da interface de usuário (UI) do restante das regras de negócio não é um assunto novo. Mesmo assim essa separação não é aplicada no dia a dia pela grande maioria dos desenvolvedores. Muitos pensam que para alcançar esse objetivo seria necessário alterar toda sua programação, abandonar o estilo RAD (Rapid Application Development) do Delphi e se voltar totalmente para a Orientação a Objetos.

É muito comum encontrar projetos onde os códigos para exibição de dados, sentenças SQL e validação de negócio estão centralizados nos formulários, esse é o famoso código espaguete ou macarrônico. Fazer um projeto dessa maneira é muito rápido e em tese, não é errado, pois o que importa é resolver o problema de um cliente. Mas além de pensar simplesmente nisso seria bom pensar também na vida desse projeto.

Existe uma fase no ciclo de vida de um projeto intitulada manutenção. Nela são implementadas melhorias, correções e até mesmo novos recursos. Essa fase pode fazer com que um projeto seja menos competitivo que outro ou até mesmo mais custoso. Neste caso, pode-se dizer ser menos competitivo porque dependendo de como foi escrito, alterar uma rotina pode levar dias, semanas. E consequentemente isso gera custo, o que torna cara a manutenção. O código macarrônico causa essa situação.

As camadas do projeto são amarradas entre si, gerando uma dependência desnecessária, impossibilitando a reutilização de rotinas, regras de negócio. Sem falar a aplicação de rotinas consagradas para atestar qualidade, como testes unitários.

Arquitetura

Em um sistema com boa arquitetura encontramos algumas divisões lógicas que visam facilitar a manutenção e adição de novos recursos. Essas camadas podem ser vistas na Figura 1.

Figura 1. Camadas lógicas de um software

Para entender a funcionalidade de cada camada, vamos aplicar um exemplo comum, uma situação conhecida por todos, um formulário de cadastro. Esse formulário representa a camada de apresentação do sistema, isto porque é nela que os dados são apresentados ao usuário.

Em um sistema Cliente/Servidor, a sua camada de domínio, de base dados e até mesmo serviços podem ser representadas pelos Data Modules existentes e seus componentes de acesso ao banco de dados.

Por último, temos a camada global que pode ser representada pelo seu conjunto de funções e procedimentos públicos.

Continuando com o paralelo a um sistema comum, desenvolvido de forma macarrônica, nos formulários nós fazemos acesso direto aos Data Modules, aos ClientDataSets, geramos SQL, tudo sem preocupação alguma, ou seja, nós misturamos o que seriam nossas camadas sendo que o correto é separar as camadas.

Quando essas camadas se misturam é dito que existe um acoplamento entre elas. No momento que você insere código SQL em evento OnClick de um botão o acoplamento foi realizado. Seu formulário, que é sua camada de apresentação, está fazendo acesso direto aos recursos do que seria sua camada de dados. Isso impede a reutilização da lógica contida no formulário. Tudo isso dificulta a manutenção do seu sistema porque você terá SQL espalhado por todo código e não apenas centralizado em uma área.

Outra prática que é muito comum é de se criar os eventos e dentro deles escrever um código tão longo que para entender o que está sendo feito é quase como ler um livro. Consequentemente a rotina ali dentro poderia ser quebrada em classes ou funções.

Quando uma rotina faz mais do que foi projetada a fazer é dito que existe uma baixa coesão nela. A baixa coesão é outro problema para a boa manutenção do seu Software. Então, como podemos separar as camadas sem evitando a baixa coesão e alto acoplamento?

Quem já está no mercado há algum tempo com certeza já ouviu sobre os padrões MVC (Model-View-Controller) ou MVP (Model-View-Presenter). Esses padrões de projeto, que são soluções atestadas por vários desenvolvedores, sugerem uma solução à separação da UI. Esses são padrões bem genéricos, que podem ser implementados por qualquer linguagem orientada a objetos, visto que não utilizam recursos específicos.

O MVC para separar a camada de apresentação cria três partes distintas, o Model, a View e o Controller. Podemos defini-los da seguinte forma: Model – É a representação da informação que a aplicação utiliza; View – É a representação gráfica do Model. Por exemplo, um formulário expondo as informações de um cliente. Uma View está sempre ligada a um model e sabe como exibi-lo ao usuário. Além disso, também pode ser composta por várias Views; Controller – É responsável em mapear as ações do usuário em ações do sistema, por exemplo, se um botão ou item de menu é clicado é ele que deve definir como a aplicação responderá. O MVP é por sua vez, uma extensão do MVC, tratando a View apenas como uma camada simples que implementa uma Interface contendo todas as propriedades e métodos necessários para o funcionamento da aplicação. Dessa maneira, se precisarmos incluir uma nova camada de apresentação, basta implementar a Interface em questão e a mesma funcionará da mesma maneira. Enquanto no MVC a View tem acesso ao Model e ao Controller, tornando assim a relação fortemente acoplada, no MVP a View “conhece” apenas o Presenter, possibilitando que o Presenter faça o “meio de campo” entre as demais camadas.

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