2. Un enfoque de desarrollo MVC en web/PHP

Proponemos aquí un enfoque para el desarrollo de aplicaciones web/PHP que respeten la arquitectura MVC. Su único objetivo es abrir nuevas vías. El lector lo adaptará a sus gustos y necesidades.

Comenzaremos por definir todas las vistas de la aplicación. Estas son las páginas web que se muestran al usuario. Nos pondremos en su lugar para diseñar las vistas. Se distinguen tres tipos de vistas:
- el formulario de entrada, cuyo objetivo es obtener información del usuario. Este suele disponer de un botón para enviar al servidor la información introducida.
- La página de respuesta, que solo sirve para proporcionar información al usuario. A menudo cuenta con uno o varios enlaces que permiten al usuario continuar con la aplicación en otra página.
- la página mixta: el controlador ha enviado al cliente una página que contiene información que él mismo ha generado. Esta misma página servirá al cliente para proporcionar al controlador nueva información procedente del usuario.

Cada vista dará lugar a una página PHP. Para cada una de ellas:
- se diseñará el aspecto de la página
- Se determinarán cuáles son las partes dinámicas de la misma:
  - la información destinada al usuario que deberá proporcionar el controlador como parámetros a la vista PHP. Una solución sencilla es la siguiente:
    - el controlador coloca en un diccionario $dReponse la información que desea proporcionar a una vista V
    - el controlador muestra la vista V. Si esta corresponde al archivo fuente V.php, esta visualización se obtiene simplemente mediante la instrucción include V.php.
    - La inclusión anterior es una inclusión de código en el controlador. Se puede acceder directamente al diccionario $dReponse, rellenado por este, mediante el código de V.php.
  - Los datos de entrada que deberán transmitirse al programa principal para su procesamiento. Estos deberán formar parte de un formulario HTML (etiqueta <form>).

Se pueden esquematizar las E/S de cada vista

las entradas son los datos que deberá proporcionar el controlador a la página PHP
las salidas son los datos que deberá proporcionar la página PHP al controlador de la aplicación. Forman parte de un formulario HTML y el controlador las recuperará mediante una operación del tipo $_GET["param"] (método GET) o $_POST["param"] (método POST).

A menudo, la página final enviada al cliente no es una vista, sino una composición de vistas. Por ejemplo, la página enviada a un usuario puede tener la siguiente forma:

La zona 1 puede ser un banner de título, la zona 2 un banner de menú y la zona 3 una zona de contenido. En PHP, esta composición se puede obtener mediante el siguiente código HTML/PHP:

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

Se puede hacer que este código sea dinámico escribiendo:

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

Esta composición de vistas puede ser el único formato de la respuesta enviada al usuario. En este caso, cada respuesta al cliente deberá establecer los tres URL que se cargarán en las tres zonas antes de mostrar la página de respuesta. Se puede generalizar este ejemplo imaginando que existen varios modelos posibles para la página de respuesta. Por lo tanto, la respuesta al cliente deberá:

establecer el modelo que se va a utilizar
establecer los elementos que se deben incluir en él
solicitar la visualización del modelo

Escribiremos el código PHP/HTML de cada modelo de respuesta. Su código suele ser sencillo. El del ejemplo anterior podría ser:

<?php
    // inicializaciones para pruebas sin 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>

Siempre que sea posible, se utilizará una hoja de estilo para poder cambiar el «aspecto» de la respuesta sin tener que modificar el código PHP/HTML.

Escribiremos el código PHP/HTML de cada vista elemental. Por lo general, tendrá la siguiente forma:

<?php
     // posiblemente algunas inicializaciones, especialmente en la fase de depuración
    ...
?>

<balise>
...
         // aquí se intentará minimizar el código PHP
</balise>

Cabe señalar que una vista elemental se integra en un modelo. Su código HTML se integra dentro del código de este último. En la mayoría de los casos, este último ya incluye las etiquetas <html>, <head> y <body>. Por lo tanto, es poco frecuente encontrar estas etiquetas en una vista elemental.

Se pueden realizar pruebas de los distintos modelos de respuesta y vistas elementales

Se prueba cada modelo de respuesta. Si un modelo se llama modele1.php, se solicitará con un navegador el URL http://localhost/chemin/modele1.php El modelo espera valores del controlador. Aquí se llama directamente y no a través del controlador. El modelo no recibirá los parámetros esperados. Para que las pruebas sean posibles de todos modos, se inicializarán manualmente, con constantes, los parámetros esperados en la página PHP del modelo.
Se prueban todos los modelos, así como todas las vistas elementales. También es el momento de elaborar los primeros elementos de las hojas de estilo utilizadas.

A continuación, se escribe la lógica de la aplicación:

El controlador o programa principal gestiona, por lo general, varias acciones. Es necesario que en las solicitudes que le llegan se defina la acción a realizar. Esto puede hacerse mediante un parámetro de la solicitud que aquí llamaremos acción:
- si la solicitud procede de un formulario (<form>), este parámetro puede ser un parámetro oculto del formulario:

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

(continuación)
- si la solicitud proviene de un enlace, se puede configurar este:

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

El controlador puede empezar por leer el valor de este parámetro y luego delegar el procesamiento de la solicitud a un módulo encargado de gestionar este tipo de solicitudes. En este caso, hemos supuesto que todo se controla mediante un único script llamado main.php. Si la aplicación debe gestionar acciones action1, action2, ..., actionx, se puede crear dentro del controlador una función por acción. Si hay muchas acciones, se puede llegar a tener un controlador «dinosaurio». También se pueden crear scripts action1.php, action2.php, ...,actionx.php encargados de procesar cada una de las acciones. El controlador que deba procesar la acción actionx se limitará a cargar el código del script correspondiente mediante una instrucción del tipo include «actionx.php». La ventaja de este método es que se trabaja fuera del código del controlador. De este modo, cada miembro del equipo de desarrollo puede trabajar en el script de procesamiento de una acción actionx de forma relativamente independiente. La inclusión del código del script actionx.php en el código del controlador en el momento de la ejecución tiene también la ventaja de aligerar el código cargado en memoria. Solo se carga el código de procesamiento de la acción en curso. Esta inclusión de código hace que las variables del controlador puedan entrar en conflicto con las del script de la acción. Veremos que podemos hacer lo necesario para limitar las variables del controlador a unas pocas variables bien definidas, que entonces habrá que evitar utilizar en los scripts.

Se buscará sistemáticamente aislar el código de negocio o el código de acceso a los datos persistentes en módulos separados. El controlador es una especie de jefe de equipo que recibe solicitudes de sus clientes (clientes web) y las hace ejecutar por las personas más adecuadas (los módulos de negocio). Al escribir el controlador, se determinará la interfaz de los módulos de negocio que hay que escribir. Esto si dichos módulos de negocio están por construir. Si ya existen, entonces el controlador se adaptará a la interfaz de dichos módulos existentes.

Se escribirá el esqueleto de los módulos de negocio necesarios para el controlador. Por ejemplo, si este utiliza un módulo getCodes que devuelve una tabla de cadenas de caracteres, en un primer momento bastará con escribir:

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

A continuación, se puede pasar a las pruebas del controlador y de los scripts PHP asociados:

el controlador, los scripts de acciones, los modelos, las vistas y los recursos necesarios para la aplicación (imágenes, etc.) se colocan en la carpeta DC asociada al contexto C de la aplicación.
Una vez hecho esto, se prueba la aplicación y se corrigen los primeros errores. Si main.php es el controlador y C el contexto de la aplicación, se solicitará el URL http://localhost/C/main.php. Al final de esta fase, la arquitectura de la aplicación está operativa. Esta fase de prueba puede resultar complicada, ya que se dispone de pocas herramientas de depuración si no se utilizan entornos de desarrollo avanzados y, por lo general, de pago. Podemos ayudarnos de instrucciones echo «mensaje» que escriben en el flujo HTML enviado al cliente y que, por lo tanto, aparecen en la página web mostrada por el navegador.

Por último, se escriben las clases de negocio que necesita el controlador. Aquí se trata, por lo general, del desarrollo clásico de una clase PHP, que suele ser independiente de cualquier aplicación web. En primer lugar, se probará fuera de este entorno, con una aplicación de consola, por ejemplo. Una vez escrita una clase de negocio, se integra en la arquitectura de implementación de la aplicación web y se comprueba su correcta integración. Se procederá así para cada clase de negocio.