PHP: Uma introdução suave ao MVC (Parte 2)

Na primeira parte, vimos como desmontar um script PHP tradicional, separando a lógica de negócios da apresentação. Este foi o maior passo a ser feito: a partir de agora, nós vamos ajustar essa separação adicionando um terceiro cara na equação: o model. Senhoras e senhores, esta é a parte 2 de uma introdução suave ao MVC.

Parte 2: MVC completo

O MVC defende Modelo/Visão/Controle. É um padrão de projeto defendendo o uso de três camadas:

o model: o model é a camada de acesso aos dados, a única responsável por recolher dados requisitados (por exemplo, funções como getAllMembers() retornando um array PHP com todos os membros nele, ou addMember($name, $age, $city) para adicionar um membro novo no banco de dados).

o view: o view é a camada de apresentação onde é gerada a saída (o HTML final na página WEB exibindo os nomes dos membros com PHP usado como uma linguagem de template como em <li><?php echo $member['name']; ?></li>)

o controller: o controller destina-se a coordenar todo o processo analisando as requisições, executando o modelo correpondente para obter os dados (chamando getAllMembers() e colocando o array retornado na variável PHP $members), chama o view correspondente (include 'tpl/template.php') e preenche-o com dados ($members) e então envia a saída.

Aqui está um gráfico simples para entender melhor o padrão de projeto MVC:

A nova arquitetura dá mais flexibilidade na construção da aplicação:

• a camada de acesso aos dados é terceirizada para o modelo, assim podemos trabalhar com uma abstração de dados: os dados armazenados podem estar em um banco de dados ou em arquivos XML, continuaremos acessando a lista de membros através da função getAllMembers().

• a camada de apresentação é terceirizada para a view: se quisermos que a saída seja um feed RSS ao invés de uma página HTML, nós teremos apenas que mudar o view sem interferir na lógica ou no acesso aos dados.

Como você pode ver, o MVC é extremamente poderoso porque ele possibilita a divisão do script em partes naturalmente independentes, o que torna verdadeiro o velho sonho de reusabilidade: por exemplo, se quisermos que a saída seja tanto uma página HTML quanto um feed RSS exibindo todos os membros do community.com, podemos reutilizar o mesmo modelo e simplesmente criar dois templates diferentes (os arquivos 'tpl/template.php' e 'tpl/rss.php').

Agora vamos voltar para a implementação do padrão de projeto MVC. Chamando o controller diretamente através do endereço http://community.com/members.php, ele pode ser melhorado um pouco mais. Ao invés de chama-lo diretamente, vamos criar um ponto de entrada único chamado de router especificando que nós queremos mostrar os membros da página, este router analisará a requisição e entenderá que nós queremos mostrar a página membros, e executará o controller members.php. No CodeIgniter por exemplo, o ponto de entrada único é chamado de index.php e se quisermos chamar o controller members, teremos que digitar a seguinte URL: http://community.com/index.php/members. Nós também podemos imaginar uma URL menos sexy http://community.com/index.php?controller=members ou, ao contrário, se livrar do router através de algumas reescritas de URL e apenas chamar um elegante http://community.com/members.

Aqui está o que adicionamos ou clareamos nesta implementação MVC:

• o router é o único ponto de entrada da aplicação que analisa cada requisição e carrega o controller correspondente.

• o modelo interage com o banco de dados (mais uma vez, pode ser um conjunto de arquivos XML ou qualquer outra maneira de guardar dados, nós teríamos apenas que reescrever o modelo sem se preocupar com a saída final)

• agora o view se torna o layout principal, que por sua vez, pode incluir sub-templates reutilizáveis (isto é diretamente inspirado no Ruby on Rails e tem sido reproduzido em muitos frameworks web)

Referências
Nemetral - Artigo Original (Parte 2)