Después de haber realizado una investigación sobre el tema, he hallado una serie de enlaces, donde se destacan cosas como que el único MVC oficialmente creado para PHP es phpMVC, o cosas como que MVC no es para PHP. ¿Lo comentamos?

Actualización (2021-06-02): corregida un poco la redacción y los enlaces. Han pasado ya 15 años y ninguno de los tres enlaces funciona. Menos mal que disponemos del web archive.

En principio, buscando alternativas, además de phpMVC tan solo encontré Kenda, el cual se encuentra en un estado muy inicial y con muy poco apoyo.

Personas como Jim Lim, creador de ADODB, consideran mala idea usar MVC en PHP. Principalmente, porque parece que nadie sabe aún como hacerlo. En su blog, Jim, señala seis puntos para los que MVC suele fallar:

  1. Control centralizado sobre los derechos y accesos a la página
  2. Habilidad para remapear URLs debido a cambios en la estructura web
  3. Manejar inteligentemente errores 404
  4. Habilidad para, dinámicamente, añadir cabeceras y pies a páginas para mostrar alertas tales como sistema se apagará a las 5:00.
  5. Separar el contenido de la presentación de una forma razonable, ej. con plantillas.
  6. Administración de datos manchados (ej. GET, POST, COOKIES)

Con estas premisas, nos queda investigar un poco en, ¿qué es exactamente MVC? y así podremos responder la pregunta que motiva este artículo.

  • M: Modelo, es la lógica de negocio, es decir, toda función que nos permite extraer datos, ya sea de una base de datos, con proceso intermedio o sin él.

  • V: Vista, es la presentación de la aplicación. Se basa en tomar los datos con los que se tiene que formar una presentación y conformar el documento, ya sea HTML, WML, XML o cualquier formato de salida hacia el usuario.

  • C: Controlador, es la parte define el flujo de usabilidad de la aplicación. Dónde se comienza, qué debe suceder después y donde se implementan los protocolos de seguridad.

En este respecto, sobre el Modelo tenemos ADODB, que nos permite abstraernos de la base de datos para preocuparnos solo de la lógica de negocio propiamente dicha, es decir, los algoritmos que se necesitan para procesar los datos.

En la vista tenemos varias optativas, una de ellas es el uso de Smarty. Esta librería ofrece una conversión de etiquetas al estilo XML dentro de un documento de plantilla HTML, lo cual sirve para que el diseñador realice la página de plantilla sin problemas y, el programador, utilice la misma, u otras, sin variar su código.

En la vista también es usual el uso de XML/XSLT. La salida hacia el navegador se realiza en XML teniendo en cuenta solo la organización de los datos que se deben enviar al cliente y, una hoja de transformación (XSLT) se encarga de transformar ese fichero XML en un fichero HTML, WML.

La parte del controlador es algo más crítica y, a su vez, la más importante. En los proyectos phpMVC y Kenda, lo que se ofrece es, justamente, esta parte en forma de frameworks. No obstante, siempre está la opción de hacerlo uno mismo, puesto que PHP en sí, contiene suficiente funcionalidad en su API como para realizar la gestión de todo lo que realiza el controlador de forma asequible.

Después de haber introducido el debate, ¿es correcto el uso de MVC en PHP? a lo que podemos responder que sí, si el proyecto es grande y requiere de una clara división de Modelo y Vista (programadores y diseñadores) pero a su vez es simple y, no, si el proyecto es pequeño o con muchos matices complejos de gestión de accesos, permisos y control de fallos desde el servidor.

¿Qué opináis?