En intelligenia tenemos un fuerte compromiso con el software libre. En varios de nuestros proyectos hemos usado este ORM para facilitarnos el trabajo. Ahora lo hemos liberado para que tu también puedas usarlo en tus aplicaciones web modernas. Sigue leyendo para descubrir Lulo, una pequeña pero poderosa herramienta para desarrollar aplicaciones web en PHP mucho más rápido.¿Qué es?
Es un Object-Relational-Mapper para PHP. Inspirado en Django, busca trasladar algunos de los conceptos de este framework a PHP.
Evidentemente la funcionalidad que tiene ahora mismo es algo reducida y esperamos a lo largo de este año ampliarla, pero ya se puede usar en su estado actual.
¿Cuál es el objetivo de esto?
Hay multitud de frameworks para desarrollar aplicaciones, pero ¿qué ocurre cuando necesitamos una herramienta potente que nos evite los problemas de tratar con la base de datos y hemos de integrarla con otro proyecto? Entonces es donde entra en acción Lulo.
Lulo es muy sencillo y apenas tiene dependencias ni requiere configuración, lo que lo hace perfecto para acoplarlo a un proyecto ya existente o para usarlo en un proyecto de tamaño pequeño o medio.
¿Qué arquitectura software tiene?
Como se ve en la siguiente imagen, AdoDB y Twig proporcionan el soporte de la capa de abstracción DB. La clase DB tiene multitud de métodos de acceso a bases de datos, pero se puede heredar de ella y sobrescribir las operaciones que se necesite.
Luego, las clases ROModel, RWModel y LuloModel proporcionan todas las herramientas a los modelos para leer, escribir, actualizar y eliminar información de la base de datos. De esta forma, el desarrollador se olvida completamente de tener que ejecutar sentencias SQL sobre la base de datos manualmente.
Cómo se usa
Usar estos modelos es muy sencillo. Está pensado para no tener que escribir mucho código a la hora de definir los modelos.
Cargador dinámico de clases
Dado que hay relaciones entre modelos, defínete un cargador automático de clases.
Restricciones
La tabla sobre las que se basa un modelo ha de tener un atributo autoincrementado único. Normalmente este atributo se le llama id, pero puede cambiarse el nombre sobrescribiendo en el modelo la constante de clase ID_ATTRIBUTE_NAME.
Definición de un modelo
Para definir un modelo, crea una clase que herede de LuloModel y sobrescriba los siguiente atributos:
TABLE_NAME: cadena con el nombre de la tabla. Constante de clase.
CLASS_NAME: cadena con el nombre de la clase. Constante de clase.
META: array con metainformación de la clase como su nombre legible por humanos. Atributo estático.
ATTRIBUTES: array con la información sobre los atributos de clase. Atributo estático. Cada atributo es un array en el que cada clave es el nombre del atributo y el valor es otro array con la siguiente estructura:
- type: tipo del atributo.
- subtype: subtipo si el tipo es string
- max_length: longitud máxima si es de tipo string.
- default: valor por defecto.
- null: si es true el atributo es nullable.
- verbose_name: nombre legible por humanos del atributo.
- auto: si es true se calcula de forma automática.
Por ejemplo, atributos de la clase User de ejemplo:
PK_ATTRIBUTES: array con los nombres de los atributos que forman la clave primaria. Atributo estático.
RELATED_MODELS: array con los nombres de las clases con las que tiene alguna relación, sea inversa o directa. Atributo estático.
RELATIONSHIPS: array con las relaciones que tiene este modelo. Atributo estático. Sólo hay que definir las relaciones en el extremo "muchos" de las relaciones. Si es una relación muchos-a-muchos, defínela en el extremo más débil, pero sólo en uno de los modelos.
- type: tipo de relación. Puede ser ManyToMany, OneToOne o ForeigneKey
- model: modelo remoto con el que tiene la relación.
- verbose_name: nombre legible por humanos de la relación
- related_name: nombre de la relación inversa.
- related_verbose_name: nombre legible por humanos de la relación inversa.
- readonly: indica si la relación es de sólo lectura.
- on_master_deletion: indica si cuando se elimine el objeto maestro se ha de eliminar el sirviente también o poner a nulos los atributos que mantienen el enlace.
Si es una relación ManyToMany:
- junctions: lista con los nombres de las tablas intermedias. Si son más de una, la relación será de sólo lectura.
- conditions: condiciones entre la tabla origen y el primer nexo, entre el primer nexo y el segundo y así hasta la tabla final.
- unique: si la relación muchos a muchos es única.
Si es una relación ForeignKey:
- condition: condición de enlace entre los atributos de este modelo y el modelo padre relacionado.
- nulllable: si la relación puede ser nulable o no. En realidad, esto depende de si los atributos que mantienen el enlace son nulables o no.
No olvides llamar al método init al finalizar la declaración de la clase. Ese método inicializa las relaciones inversas a partir de las que defines en los modelos, por lo que si no lo llamas, éstas no funcionarán.
Una vez hecho esto, ya puedes empezar a trabajar.
Operaciones
Lectura
- dbLoad: permite obtener un objeto de este modelo pasándole una condición.
- dbLoadAll: permite obtener los objetos de este modelo pasándole una condición, un orden y un límite. El resultado se puede obtener como una Query, QueryResult o un Collection.
Todas las escrituras se ejecutan con dbSave. Si el objeto ya existe en la tabla, él se encargará de ejecutar la actualización en vez de la inserción.
Hay una operación dbUpdate que permite hacer actualizaciones sobre los datos de la tabla del modelo, pero salvo que la necesites expresamente, no te aconsejo usarla.
Queries y Collections
Los objetos Query son abstracciones de consultas sobre la tabla del modelo. De forma similar a como funcionan los QuerySet de Django, los objetos Query permiten obtener, actualizar y eliminar datos de forma eficiente.
Los QueryResult son un tipo de objeto más eficiente aún que los Query pero que sólo permite consultas sobre la tabla del modelo. Están marcados como deprecated y puede que en las siguientes versiones de Lulo los eliminemos.
Las colecciones (Collection) son objetos que permiten trabajar en memoria con los objetos de los modelos. Su uso como almacén de datos obtenidos a partir de una consulta está desaconsejado ya que no hacen uso de los cursores de la tabla y son muy ineficientes en cuanto a consumo de memoria.
¿Qué dependencias tiene?Depende de PHP 5.6, AdoDB y del sistema de plantillas Twig.
Las dependencias están preparadas en un fichero de instalación de composer, por lo que no deberías tener problemas en instalarlas.
A nivel de base de datos hemos hecho todos los desarrollos con MySQL, pero el código SQL está preparado para funcionar con PostgreSQL correctamente. Si te animas a usarlo con algún otro SGBD, ¡háznoslo saber!
¿Cómo puedo instalarlo?
Puedes ver el código y la documentación en la página del proyecto en github.
Clona el repositorio y ¡ya lo tienes todo!
¿Hay algún ejemplo?
Sí, hemos liberado varias clases de una aplicación ficticia similar a una red social. Las puedes ver aquí.
Hay documentación más extensa en la siguiente carpeta del respositorio.
¿Puedo usarlo?
Sí y te animamos a ello. Lo hemos liberado bajo licencia MIT, por lo que podrás incluirlo en tus aplicaciones privativas o libres sin problema.
¿Y si necesito una funcionalidad concreta?
¡Perfecto! Estamos buscando colaboradores, ¿te atreves a ser parte del equipo de desarrollo de Lulo?
¿Y ahora qué?
Ahora te toca clonar el repositorio, leer la documentación y hacer experimentos.
Y por supuesto, deja tu opinión sobre esta herramienta en los comentarios, estaré encantado de leerlos y comentarlos :)
Y por supuesto, deja tu opinión sobre esta herramienta en los comentarios, estaré encantado de leerlos y comentarlos :)
Diego
No hay comentarios:
Publicar un comentario