PHP y la programación en 3 capas
Tengo un problemilla con la programación orientada a objetos (POO). Mi primer programa lo hice, tendría yo unos 13 años, con mi primer MSX y en un BASIC clásico. Terminé de estudiar en 1989 y hasta ese momento la metodología reina era la estructurada.
Luego trabajé hasta 1996 en empresas donde desarrollaba aplicaciones de gestión en Clipper utilizando metodología estructurada y haciendo uso de los primeros pseudo-objetos que me encontraba en Clipper 5 (y aún pervive en The Harbour Project). Pero el desarrollo seguía siendo eminentemente estructurado.
Recuerdo que en los equipos de programación en los que participé, creabamos librerías enormes con un ingente recopilación de funciones y procedimientos que facilitaban mucho la tarea de crear nuevos aplicativos. Siempre con la misma idea en mente: reutilización de código; objetivo final: programar cada vez menos líneas y reducir los tiempos de desarrollo.
(Durante ese tiempo y entre medias toqué muchos palos: COBOL, Pascal, C, Ensamblador, BASIC Prologue, macros de Microsoft Office y su VBA de Access... ¡cualquier cosa que sirviera para programar! ¡Hasta algún que otra EPROM!)
Luego, en 1996 di el salto a la red, a Internet, el HTML fue cosa de un par de días pero la necesidad de generar páginas dinámicas era evidente y empecé con Perl hasta que desembarqué en PHP, comenzando una relación estable y duradera que va ya para 10 años. Las primeras versiones de Perl y las primeras que utilicé de PHP no estaban muy orientadas a objeto; la programación estructurada y las bibliotecas de funciones y procedimientos seguían siendo la metodología estrella.
Fue la versión 4 de PHP la que empieza a introducir de manera interesante la POO pero no es hasta la versión 5 que se empieza a dar un verdadero salto hacia esta metodología de programación. Con la versión 6 se espera un entorno de desarrollo puro POO. Los programadores senior (rozando la cuarentena) lo tenemos claro: aprender, adaptarse... o cambiar de profesión.
Y por qué te dejo caer toda esta introducción que ni viene ni va ni interesa a la mayor parte de los lectores. Para llegar a la situación actual. Recientemente me han puesto delante de las narices, de buenas maneras, un reto extremadamente interesante. Construir un entorno de desarrollo de aplicaciones de gestión a medida, vía web, modular, construído en 3 capas (motor o núcleo, interfaces o plantillas y gestión de datos). La propuesta inicial era utilizar Java, cosa que personalmente no es de mi gusto dadas las exigencias de consumo de recursos, la necesidad de instalar una máquina virtual Java en el usuario cliente y, lo reconozco, tener que aprender un nuevo lenguaje, filosofía, entornos (como Eclipse)...
PHP no está orientado a un desarrollo por capas como puede ser Java. ¡Oh! Pero, por otro lado, ya muchos desarrollos de rotundo éxito lo hacen. De hecho, prácticamente todos los entornos de publicación web, de amplia difusión en la red ahora mismo, sean libres o bajo licencia, llámense Joomla!, osCommerce, eGroupWare, vBulletin, phpBB..., lo usan.
¿Y cuál es la idea? Utilizar dos sencillas instrucciones: require e include (o más exactamente sus versiones más restrictivas require_once e include_once). Su funcionalidad es extremadamente simple. Pasando como parámetro un fichero dado que, en teoría, debe contener código PHP, injerta ese contenido en al línea donde se usa esta instrucción. La diferencia entre ambas es que la primera requiere que exista ese archivo o en caso contrario genera un error grave, interrumpiendo la ejecución del código; y en el segundo caso simplemente se incluye el código si existe el archivo o en caso contrario se genera un aviso de error (o warning), continuando la ejecución del código llamante. En el caso de usar las alternativas _once, la funcionalidad es idéntica, sólo que si ya se ha incluido el archivo pasado como parámetro, no se vuelve a incluir.
Un ejemplo:
Ejemplo: fichero1.php
echo "inicio fichero 1\n";
require("fichero2.php");
echo "fin fichero 1\n";
Ejemplo: fichero2.php
echo "inicio fichero 2\n";
echo "finfichero 2\n";
Resultado de salida:
» inicio fichero 1
» inicio fichero 2
» fin fichero 2
» fin fichero 1
Hay que entender que require e include incrustan el código del fichero referenciado como parámetro. Es decir, en la práctica es como si hubieramos generado un único archivo de ejecución. Es un detalle a tener en cuenta dado que nombres de variables, clases y funciones están dentro del mismo ámbito y un error habitual son las redeclaraciones.
¿Qué hago yo con todo esto? La idea es programar un núcleo, un index.php que prepara un entorno de lanzamiento, llama a una plantilla predeterminada (un pseudo index.html) y ésta a los módulos de gestión de datos que pueden empaquetarse artificiosamente en subdirectorios (por ejemplo, contabilidad/cuentas.php).
En el gráfico adjunto se muestra mejor la idea, que extraje, todo sea dicho, de la estructura de Joomla!, aunque el resultado no sea idéntico, allí encontré la inspiración para aplicar una solución ya inventada.
El núcleo central controla la identificación del usuario, sus permisos y prepara las librerías de funciones, clases y variables globales necesarias, llamando a la plantilla asociada al usuario que se conecta.
La plantilla controla la interacción del usuario y lanza los módulos que el usuario demanda.
Los módulos de gestión de datos utilizan los includes (funciones, clases y variables globales) que necesite y que ha puesto a su disposición el núcleo central de la aplicación.
El usuario ve un HTML final que se ha generado en dos fases. Una inicial, que genera un interface genérico, creado dinámicamente por la plantilla, más una segunda con un contenido incrustado en el resultado final que verá el usuario y generado por los módulos de datos.
Finalmente, cualquier idea, aportación o sugerencia que tengas o creas conveniente a este desarrollo, te pediría que lo compartieses en los comentarios para así tener la oportunidad de mejorar este diseño.
Luego trabajé hasta 1996 en empresas donde desarrollaba aplicaciones de gestión en Clipper utilizando metodología estructurada y haciendo uso de los primeros pseudo-objetos que me encontraba en Clipper 5 (y aún pervive en The Harbour Project). Pero el desarrollo seguía siendo eminentemente estructurado.
Recuerdo que en los equipos de programación en los que participé, creabamos librerías enormes con un ingente recopilación de funciones y procedimientos que facilitaban mucho la tarea de crear nuevos aplicativos. Siempre con la misma idea en mente: reutilización de código; objetivo final: programar cada vez menos líneas y reducir los tiempos de desarrollo.
(Durante ese tiempo y entre medias toqué muchos palos: COBOL, Pascal, C, Ensamblador, BASIC Prologue, macros de Microsoft Office y su VBA de Access... ¡cualquier cosa que sirviera para programar! ¡Hasta algún que otra EPROM!)
Luego, en 1996 di el salto a la red, a Internet, el HTML fue cosa de un par de días pero la necesidad de generar páginas dinámicas era evidente y empecé con Perl hasta que desembarqué en PHP, comenzando una relación estable y duradera que va ya para 10 años. Las primeras versiones de Perl y las primeras que utilicé de PHP no estaban muy orientadas a objeto; la programación estructurada y las bibliotecas de funciones y procedimientos seguían siendo la metodología estrella.
Fue la versión 4 de PHP la que empieza a introducir de manera interesante la POO pero no es hasta la versión 5 que se empieza a dar un verdadero salto hacia esta metodología de programación. Con la versión 6 se espera un entorno de desarrollo puro POO. Los programadores senior (rozando la cuarentena) lo tenemos claro: aprender, adaptarse... o cambiar de profesión.
Y por qué te dejo caer toda esta introducción que ni viene ni va ni interesa a la mayor parte de los lectores. Para llegar a la situación actual. Recientemente me han puesto delante de las narices, de buenas maneras, un reto extremadamente interesante. Construir un entorno de desarrollo de aplicaciones de gestión a medida, vía web, modular, construído en 3 capas (motor o núcleo, interfaces o plantillas y gestión de datos). La propuesta inicial era utilizar Java, cosa que personalmente no es de mi gusto dadas las exigencias de consumo de recursos, la necesidad de instalar una máquina virtual Java en el usuario cliente y, lo reconozco, tener que aprender un nuevo lenguaje, filosofía, entornos (como Eclipse)...
PHP no está orientado a un desarrollo por capas como puede ser Java. ¡Oh! Pero, por otro lado, ya muchos desarrollos de rotundo éxito lo hacen. De hecho, prácticamente todos los entornos de publicación web, de amplia difusión en la red ahora mismo, sean libres o bajo licencia, llámense Joomla!, osCommerce, eGroupWare, vBulletin, phpBB..., lo usan.
¿Y cuál es la idea? Utilizar dos sencillas instrucciones: require e include (o más exactamente sus versiones más restrictivas require_once e include_once). Su funcionalidad es extremadamente simple. Pasando como parámetro un fichero dado que, en teoría, debe contener código PHP, injerta ese contenido en al línea donde se usa esta instrucción. La diferencia entre ambas es que la primera requiere que exista ese archivo o en caso contrario genera un error grave, interrumpiendo la ejecución del código; y en el segundo caso simplemente se incluye el código si existe el archivo o en caso contrario se genera un aviso de error (o warning), continuando la ejecución del código llamante. En el caso de usar las alternativas _once, la funcionalidad es idéntica, sólo que si ya se ha incluido el archivo pasado como parámetro, no se vuelve a incluir.
Un ejemplo:
Ejemplo: fichero1.php
echo "inicio fichero 1\n";
require("fichero2.php");
echo "fin fichero 1\n";
Ejemplo: fichero2.php
echo "inicio fichero 2\n";
echo "finfichero 2\n";
Resultado de salida:
» inicio fichero 1
» inicio fichero 2
» fin fichero 2
» fin fichero 1
Hay que entender que require e include incrustan el código del fichero referenciado como parámetro. Es decir, en la práctica es como si hubieramos generado un único archivo de ejecución. Es un detalle a tener en cuenta dado que nombres de variables, clases y funciones están dentro del mismo ámbito y un error habitual son las redeclaraciones.
¿Qué hago yo con todo esto? La idea es programar un núcleo, un index.php que prepara un entorno de lanzamiento, llama a una plantilla predeterminada (un pseudo index.html) y ésta a los módulos de gestión de datos que pueden empaquetarse artificiosamente en subdirectorios (por ejemplo, contabilidad/cuentas.php).
En el gráfico adjunto se muestra mejor la idea, que extraje, todo sea dicho, de la estructura de Joomla!, aunque el resultado no sea idéntico, allí encontré la inspiración para aplicar una solución ya inventada.
El núcleo central controla la identificación del usuario, sus permisos y prepara las librerías de funciones, clases y variables globales necesarias, llamando a la plantilla asociada al usuario que se conecta.
La plantilla controla la interacción del usuario y lanza los módulos que el usuario demanda.
Los módulos de gestión de datos utilizan los includes (funciones, clases y variables globales) que necesite y que ha puesto a su disposición el núcleo central de la aplicación.
El usuario ve un HTML final que se ha generado en dos fases. Una inicial, que genera un interface genérico, creado dinámicamente por la plantilla, más una segunda con un contenido incrustado en el resultado final que verá el usuario y generado por los módulos de datos.
Finalmente, cualquier idea, aportación o sugerencia que tengas o creas conveniente a este desarrollo, te pediría que lo compartieses en los comentarios para así tener la oportunidad de mejorar este diseño.
Comentarios
Publicar un comentario