En algunas de mis crónicas he comentado que soy parte de la generación de informáticos que se …¿educaron? ¿capacitaron? ¿crecieron?… en la década de los 1990s. Yo tuve la fortuna de conocer en vivo y funcionando una IBM PC2, una máquina con un procesador 80×286 y monitor monocromático; usar un disco 5 1/4″ con el sistema operativo para funcionar como disco de arranque y hacer nada (solo me mostraron como arrancar y dejar cargado el DOS en memoria); me decepcioné al ver Lotus 123 en DOS (porque no comprendía qué era, para qué servía y cómo usarlo); Paint en Windows 3.1; incluso vi una Apple Macintosh II y me sorprendió que para sacar un disquete no había un botón físico, tenías que hacerlo desde la interfaz gráfica, algo muy similar a lo que hoy se hace cuando se extrae una memoria USB desde Windows.
Bueno, pues en ese mismo tren de ideas, uno de los lenguajes y plataformas de desarrollo que conocí y aprendí a estimar en mis años de universidad fue PHP. Era el año 2001, inicié con la versión 3 y pronto encontré que la 4 se había hecho oficial. Para mí fue increible, ver cómo funcionaba una aplicación web dinámica, poder configurarlo todo en mi equipo con Windows 98 y además, tener acceso a un motor de base de datos gratuito, MySQL, todo ese poder al alcance del estudiante promedio con limitado acceso a internet.
Para no alargar la crónica, PHP lo dejé por motivos profesionales durante 8 años. Después, nuevamente por motivos profesionales lo retomé, ahora estaba en la version 5.6, con múltiples diferencias de lo que yo recordaba, no solo PHP, MySQL también. Ahora se tenía acceso a programación orientada a objetos, y PHP podía soportar procedimientos almacenados y contaba con más de dos motores de almacenamiento con diferentes modalidades y ventajas… aunque ahora le pertenecía a Oracle y había múltiples rumores de que pretendían detener su desarrollo.
Pues un buen día que estaba retomando el tema de PHP pensé (recuerda lo que he dicho de mi historial estudiantil y profesional):
-Es evidente que tener el html, el acceso a base de datos y la lógica de negocio en un mismo script no es buena idea, es complejo conforme el proyecto empieza a crecer.
Así que imaginé que la interfaz gráfica la podía dejar en scripts separados en una función, cada función se encargaba de mostar el código HTML de la pantalla que yo deseaba y le pasaba por parámetros la información que era dinámica. La conexión a BD ya la hacía por separado y la invocaba con la instrucción include. Entonces nuevamente en mi instrospección consideré:
-Podría hacer un script que se encargue de recopilar la información o lo que hace el usuario. En un form, en el action, podría enviar a un script que se encargue de procesar la información recibida, si es correcta, hago un redirect a una especie de script de confirmación; si es errónea, hago un redirect a la misma página original con el mensaje de error…
Esto me funcionó bastante bien. Si en este punto, esto que te describo te suena muy bien y nada de esto resuena en tu cabeza, podrás saber el júbilo que tuve cuando mi idea funcionó; si no es así, es que ya sabes qué son los patrones de diseño y a donde estaba intentando llegar (que yo ignoraba). El problema era que seguir el flujo de los datos y de la aplicación se empezaba a complicar conforme la esta crecía, tenía que mantener un mapa como este:
Adicionalmente, cada pantalla que mostraba datos al usuario era diferente, por lo que cada función que pintaba una interfaz gráfica era distinta, y no la podía reutilizar, salvo por la separación que hice de encabezados y partes que eran comunes en todas las pantallas.
Empecé a buscar una solución a mir problema, ya que probablemente alguien más habría pensado en esto… y qué razón tenía. Al describir lo que estaba haciendo y lo que pretendía lograr en mis búsquedas, aprendí que mi novedosa solución en realidad era un patrón de diseño ya entrado en años de nombre MVC (model-view-controller) y que mucha gente antes que yo había pensado en esto, no solo en la teoría, sino en la aplicación, en las distintas plataformas de desarrollo, y PHP no era la excepción. Había una oferta voluminosa de frameworks para PHP que ofrecían el patrón, si bien, las más populares y de más frecuente mención eran:
Comencé a leer acerca de Symfony. No ahondé porque la propia documentación del framework era extensa, no muy clara y en los foros, además de hacer eco de estas observaciones decían que era lento, muy funcional, pero con una curva de aprendizaje muy larga. Desistí.
Después intenté con Yii. No invertí mucho tiempo, la documentación era peor que la de symfony y los comentarios no le ayudaban.
CakePHP parecía bien, muy sencillo, la documentación ligera, pero me parecía corta e incompleta, y llevaba años estancado. En los foros ya lo daban por muerto, así que tampoco continué. Al final, los foros estaban equivocados, tiempo después CakePHP tomó nuevos bríos y parece que ha logrado recuperar terreno. Ya habrá oportunidad de hablar de él.
Zend Framework prácticamente no lo toqué. Desde mis primeros pasos en PHP, Zend tenía una fama particular, que no significa que sea mala, de hacer uso de PHP diferente al documentado y hasta tener herramientas propias de costo. Los foros no le favorecían tampoco.
Laravel era lo máximo. Cuando llegué a este framework, ya había tenido oportunidad de ver lo que algunos frameworks MVC de Java podían hacer, sobre todo la parte de tener ORMs. La documentación de Laravel indicaba que contaba con soporte para Active Record, que para mí significaba nada, pero esa característica era celebrada por la comunidad y algunos, sólo por ese particular lo ponían por encima del resto de la oferta. Así que lo intenté. Leí el Get Started de Laravel, con lo que según esto tendría un «hola mundo» funcionando en tiempo record… y no lo logré. Pese a que seguí paso a paso lo documentado, nunca hice funcionar el framework, pero como estaba marcado como lo mejor de lo mejor, decidí pausar y regresar cuando se me pasara el mal trago.
Entonces llegué a Codeigniter. De inicio, el nombre me parecía tan jocoso… codeiniter… el logo, una flama. En fin, si ya habia pasado por Yii, o Cake… habría que darle una oportunidad al igniter. Y qué bueno que no me dejé llevar por el prejucio. Seguí el Get Started y en menos de media hora, incluyendo el tiempo de lectura e instalación, mi primer controller estaba funcionando. La documentación del framework era bastante concisa y ligera, suficientemente completa en el entendido de que las dudas que surgían encontraban su respuesta en la documentación oficial.
No regresé a Laravel, continué leyendo y aprendiendo más de Codeigniter.
A los 4 años de trabajar con él, ya en otro trabajo, vi la conveniencia de tener un ORM. Codeigniter, al menos la version 3.x, no cuenta con uno. Se automatiza la conexion a bd y se tienen helpers y bibliotecas para acceder a los datos, pero por ejemplo, un insert, se tiene que hacer «a mano». Con un ORM, se mapea una tabla a una clase, y al instanciar la clase ya se puede tener acceso a base de datos. Así que comencé a buscar opciones. Encontré GAS ORM, una extensión hecha exclusiva para Codeigniter.
Hice una instalación de prueba y vaya que cumplía su cometido. Hacer un insert usando GAS, se traduce a lo siguiente:
$clase_mapeada_de_tabla->save();El método save, no solo inserta el registro en la tabla, se puede mandar un parámetro para indicar al método que en caso de existir el registro, haga un update en su lugar.
Un select * es como sigue:
$listado_registros = Model\clase_mapeada::all();El ORM entrega los datos en forma de una clase, arreglo de objetos o arreglo de datos. Es muy funcional.
Pero…
Utiliza mucha memoria. Para poder ofrecer todas las funcionalidades, aunque solo te interese obtener un registro de una tabla, GAS tiene que hacer toda la instanciación de sus estructuras de datos. De tal suerte que usando Codeigniter puro, un listado de 5 mil registros tiene una ocupación de memoria mucho menor que los mismos 5 mil registros con el ORM.
¿A qué viene todo esto?
Parece que GAS ha quedado sin soporte. Yo incorporé la versión 2 a mis proyectos. El tema de la ocupación de memoria empezó a ser un problema en cualquier operación SELECT cuando el volumen de datos comenzó a incrementarte, tuve que ir removiendo el uso de GAS y reemplazarlo con las funciones que Codeigniter tiene, de forma que mantener GAS en mi proyecto solo porque puede hacer un insert/update me parecía no tener sentido.
¿Deberías utilizarlo?
Sí, si quieres aprender y tener un ejercicio de primera mano de cómo usar un ORM con PHP, instalarlo y configurarlo es rápido y sencillo.
No, si ya pretendes oficializar tu trabajo. Es mejor usar otro ORM o definitivamente quedarte con las herramientas que codeigniter proporciona para acceso a datos. Adicionalmente, estoy hablando de Codeingniter 3.11. La versión 4 hasta donde tengo entendido, ya viene bastante reforzada en estos apartados.
Piensa a futuro tus decisiones. Agregar GAS en un inicio me pareció una buena idea porque todas mis pruebas fueron con un conjunto de datos reducido. No olvides nunca esto, una solución la debes valorar también pensando en el crecimiento de los datos. No hice una prueba así con GAS, y cuando los problemas de la volumetría comenzaron, reemplazar el uso de GAS por las herramientas de codeigniter tomó más tiempo y esfuerzo que quitarlo. Hoy día, ya eliminé toda referencia del ORM en los controllers, voy a la mitad de los models.
Esto es todo por esta crónica, espero que puedas aprender de mis errores para no caer en ellos.
$cronica->save();
Deja un comentario