2. Uma abordagem de desenvolvimento MVC em web/PHP

Propomos aqui uma abordagem para o desenvolvimento de aplicativos web/PHP que respeitem a arquitetura MVC. Ela serve apenas para abrir caminhos. O leitor poderá adaptá-la de acordo com suas preferências e necessidades.

Começaremos definindo todas as visualizações da aplicação. Estas são as páginas da web apresentadas ao usuário. Colocaremos-nos no ponto de vista do usuário para projetar as visualizações. Distinguem-se três tipos de visualizações:
- o formulário de preenchimento, que tem como objetivo obter informações do usuário. Ele geralmente possui um botão para enviar as informações inseridas ao servidor.
- a página de resposta, que serve apenas para fornecer informações ao usuário. Ela costuma conter um ou mais links que permitem ao usuário prosseguir na aplicação com outra página.
- a página mista: o controlador enviou ao cliente uma página contendo informações que ele mesmo gerou. Essa mesma página será usada pelo cliente para fornecer ao controlador novas informações provenientes do usuário.

Cada visualização gerará uma página PHP. Para cada uma delas:
- definiremos a aparência da página
- determinaremos quais são as partes dinâmicas da mesma:
  - as informações destinadas ao usuário que deverão ser fornecidas pelo controlador como parâmetros à visualização PHP. Uma solução simples é a seguinte:
    - o controlador insere em um dicionário $dReponse as informações que deseja fornecer a uma vista V
    - o controlador exibe a vista V. Se esta corresponder ao arquivo de origem V.php, essa exibição é obtida simplesmente pela instrução include V.php.
    - a inclusão anterior é uma inclusão de código no controlador. O dicionário $dReponse, preenchido por ele, é acessível diretamente pelo código de V.php.
  - os dados de entrada que deverão ser transmitidos ao programa principal para processamento. Esses dados deverão fazer parte de um formulário HTML (tag <form>).

É possível esquematizar as entradas e saídas de cada visualização

as entradas são os dados que o controlador deverá fornecer à página PHP
as saídas são os dados que a página PHP deverá fornecer ao controlador do aplicativo. Elas fazem parte de um formulário HTML e o controlador as recuperará por meio de uma operação do tipo $_GET["param"] (método GET) ou $_POST["param"] (método POST).

Frequentemente, a página final enviada ao cliente não é uma visualização, mas uma composição de visualizações. Por exemplo, a página enviada a um usuário pode ter a seguinte forma:

A área 1 pode ser um banner de título, a área 2 um banner de menu e a área 3 uma área de conteúdo. No PHP, essa composição pode ser obtida por meio do código HTML/PHP a seguir:

<table>
    <tr>
        <td><?php include zone1.php ?></td>
    </tr>
    <tr>
        <td><?php include zone2.php ?></td>
        <td><?php include zone3.php ?></td>
    </tr>
</table>

É possível tornar esse código dinâmico escrevendo:

<table>
    <tr>
        <td><?php include $dReponse['urlZone1'] ?></td>
    </tr>
    <tr>
        <td><?php include $dReponse['urlZone2'] ?></td>
        <td><?php include $dReponse['urlZone3'] ?></td>
    </tr>
</table>

Essa composição de visualizações pode ser o único formato da resposta fornecida ao usuário. Nesse caso, cada resposta ao cliente deverá definir os três URL a serem carregados nas três áreas antes de exibir a página de resposta. É possível generalizar esse exemplo imaginando que existam vários modelos possíveis para a página de resposta. A resposta ao cliente deverá, portanto:

definir o modelo a ser utilizado
definir os elementos a serem incluídos nele
solicitar a exibição do modelo

Escreveremos o código PHP/HTML de cada modelo de resposta. Seu código é geralmente simples. O do exemplo acima poderia ser:

<?php
    // inicializações para testes sem controlador
...
?>
<html>
    <head>
      <title><?php echo $dReponse['titre'] ?></title>
      <link type="text/css" href="<?php echo $dReponse['style']['url'] ?>" rel="stylesheet" />    
    </head>
  <body>      
    <table>
        <tr>
            <td><?php include $dReponse['urlZone1'] ?></td>
        </tr>
        <tr>
            <td><?php include $dReponse['urlZone2'] ?></td>
            <td><?php include $dReponse['urlZone3'] ?></td>
        </tr>
    </table>
  <body>
</html>

Sempre que possível, utilizar-se-á uma folha de estilo para poder alterar a aparência da resposta sem precisar modificar o código PHP/HTML.

Escreveremos o código PHP/HTML de cada visualização elementar. Na maioria das vezes, ele terá o seguinte formato:

<?php
     // eventualmente algumas inicializações, principalmente na fase de depuração
    ...
?>

<balise>
...
         // aqui, buscaremos minimizar o código PHP
</balise>

Observe-se que uma visualização elementar se integra a um modelo. Seu código HTML é incorporado ao código do modelo. Na maioria das vezes, este último já contém as tags <html>, <head> e <body>. Portanto, é raro encontrar essas tags em uma visualização elementar.

É possível realizar testes nos diferentes modelos de resposta e visões elementares

cada modelo de resposta é testado. Se um modelo se chamar modele1.php, acessaremos com um navegador o URL http://localhost/chemin/modele1.php O modelo espera valores do controlador. Aqui, ele é chamado diretamente, e não por meio do controlador. O modelo não receberá os parâmetros esperados. Para que os testes sejam, mesmo assim, possíveis, inicializaremos nós mesmos, com constantes, os parâmetros esperados na página PHP do modelo.
Cada modelo é testado, assim como todas as visualizações básicas. Este também é o momento de elaborar os primeiros elementos das folhas de estilo utilizadas.

Em seguida, escreve-se a lógica de aplicação do aplicativo:

O controlador, ou programa principal, geralmente gerencia várias ações. É necessário que, nas solicitações que chegam a ele, a ação a ser realizada esteja definida. Isso pode ser feito por meio de um parâmetro da solicitação, que chamaremos aqui de “ação”:
- se a solicitação vier de um formulário (<form>), esse parâmetro pode ser um parâmetro oculto do formulário:

<form ... action="/C/main.php" method="post"  ...>
<input type="hidden" name="action" value="uneAction">
...
</form>

(continuação)
- se a solicitação vier de um link, é possível configurá-lo:

 <a href="/C/main.php?action=uneAction">lien</a>

O controlador pode começar lendo o valor desse parâmetro e, em seguida, delegar o processamento da solicitação a um módulo responsável por lidar com esse tipo de solicitação. Aqui, consideramos o caso em que tudo fosse controlado por um único script chamado main.php. Se o aplicativo precisar processar as ações action1, action2, ..., actionx, é possível criar, dentro do controlador, uma função para cada ação. Se houver muitas ações, pode-se acabar com um controlador “dinossauro”. Também é possível criar scripts action1.php, action2.php, ...,actionx.php encarregados de processar cada uma das ações. O controlador responsável por processar a ação actionx se limitará a carregar o código do script correspondente por meio de uma instrução do tipo include “actionx.php”. A vantagem desse método é que se trabalha fora do código do controlador. Cada membro da equipe de desenvolvimento pode, assim, trabalhar no script de processamento de uma ação actionx de forma relativamente independente. A inclusão do código do script actionx.php no código do controlador no momento da execução também tem a vantagem de reduzir o volume de código carregado na memória. Apenas o código de processamento da ação em andamento é carregado. Essa inclusão de código faz com que as variáveis do controlador possam entrar em conflito com as do script da ação. Veremos que podemos fazer de modo a limitar as variáveis do controlador a algumas variáveis bem definidas, que deverão então ser evitadas nos scripts.

Buscaremos sistematicamente isolar o código de negócio ou o código de acesso aos dados persistentes em módulos distintos. O controlador é uma espécie de chefe de equipe que recebe solicitações de seus clientes (usuários da web) e as encaminha para que sejam executadas pelas pessoas mais adequadas (os módulos de negócio). Ao escrever o controlador, determinaremos a interface dos módulos de negócio a serem criados. Isso se esses módulos de negócio precisarem ser desenvolvidos. Se já existirem, o controlador se adaptará à interface desses módulos existentes.

Escrever-se-á a estrutura básica dos módulos de negócio necessários ao controlador. Por exemplo, se este utilizar um módulo getCodes que retorna uma tabela de cadeias de caracteres, pode-se, em um primeiro momento, limitar-se a escrever:

function getCodes(){
    return array("code1","code2","code3");
}

Em seguida, pode-se passar para os testes do controlador e dos scripts PHP associados:

o controlador, os scripts de ação, os modelos, as visualizações e os recursos necessários para a aplicação (imagens, etc.) são colocados na pasta DC associada ao contexto C da aplicação.
Feito isso, a aplicação é testada e os primeiros erros são corrigidos. Se main.php for o controlador e C o contexto da aplicação, solicitaremos o URL http://localhost/C/main.php. Ao final dessa fase, a arquitetura da aplicação está operacional. Essa fase de teste pode ser delicada, já que há poucas ferramentas de depuração disponíveis caso não se utilizem ambientes de desenvolvimento avançados e, em geral, pagos. É possível recorrer às instruções `echo "mensagem"`, que escrevem no fluxo HTML enviado ao cliente e, portanto, aparecem na página da web exibida pelo navegador.

Por fim, escrevemos as classes de negócio necessárias ao controlador. Trata-se, em geral, do desenvolvimento clássico de uma classe PHP, na maioria das vezes independente de qualquer aplicação web. Ela será testada inicialmente fora desse ambiente, por exemplo, com um aplicativo de console. Quando uma classe de negócio é criada, ela é integrada à arquitetura de implantação da aplicação web e sua integração correta é testada. Esse procedimento será seguido para cada classe de negócio.