Os presentamos una pequeña introducción teórica a ORM: Object-Relational Mapping (o Mapeo Objeto-Relacional) en la cual se muestran tanto ventajas como desventajas de esta metodología de programación y como emplearla en vuestros proyectos PHP.

Autor:

Intentando mejorar cada día en este mundo tan cambiante de la programación. Sígueme en Twitter o en GitHub. Actualmente estoy disponible para contratar.

¿Qué es ORM?

Es una técnica de programación que nos permite vincular los objetos usados en nuestro modelo de la aplicación con una base de datos relacional.

El principal problema surge porque hoy en día, prácticamente todas las aplicaciones están diseñadas para usar la Orientación a Objetos (POO), mientras que las bases de datos más extendidas son del tipo relacional.

La mayoría de aplicaciones están diseñadas orientadas a objetos, por contra los sistemas de bases de datos más extendidos son del tipo relacional.

Las bases de datos relacionales solo permiten guardar tipos de datos primitvos (enteros, cadenas de texto,etc…) por lo que no se puede guardar de forma directa los objetos de la aplicación en las tablas, sino que estos se deben de convertir antes en registros, que por lo general afectan a varias tablas. En el momento de volver a recuperar los datos, hay que hacer el proceso contrario, se deben convertir los registros en objetos.

Es entonces cuando ORM cobra importancia, ya que se encarga de forma automática de convertir los objetos en registros y viceversa, simulando así tener una base de datos orientada a objetos.

¿Por qué usar ORM?

Actualmente existen numerosos sistemas o librerías para incluír en proyectos desarrollados bajo cualquier lenguaje de programación y que en ámbitos generales nos aportan las siguientes ventajas…

Rapidez de desarrollo

La mayoría de las herramientas ORM disponibles, permiten la creación del modelo a través del esquema de la base de datos, es decir, tu creas la base de datos y la herramienta automáticamente lee el esquema de tablas y relaciones y crea un modelo ajustado.

Esto quita mucho tiempo de “coding” repetitivo y que, seguro, el sistema hace mejor que nosotros, ya que los humanos siempre podemos cometemos fallos tontos :) .

Por otro lado, una vez que se tiene el modelo creado, el programador irá mucho más rápido gracias a la metodología totalmente orientada a objetos, olvidándose así de las consultas a la base de datos.

Abstracción del motor de base de datos

Todo sistema ORM que se precie debe de generar de forma automática las consultas a la base de datos para convertir los registros en objetos (y viceversa) y éstas deben poder adaptarse a los distintos proveedores (MySql, Oracle, PostreSQL,etc…).

Esto permitirá a los desarrolladores tener una preocupación menos a la hora de comenzar un proyecto, ya que tienen la seguridad de que un cambio drástico en el proveedor de base de datos, no impactará para nada en el tiempo de vida del proyecto.

Lenguaje propio para consultas a la base de datos

Otra característica importante (de hecho seguramente la que más) es la exposición de clases y métodos que nos dan las herramientas ORM para poder extraer los datos de la forma que necesitemos (filtros, ordenaciones, agrupaciones).

Aquí es en donde los desarrolladores de la herramienta tienen que poner toda la carne en el asador, permitiendo a la gente olvidarse de la sintaxis Standard Query Language (SQL) para usar el propio lenguaje de la herramienta.

A continuación unos ejemplos de distintos sistemas ORM:

Linq

 
Northwind db = new Northwind(connectionString);
// Se usa la palabra reservada 'var' porque no hay nombre para el tipo resultante de la proyección
var q = from o in db.Orders, c in db.Customers
where o.Quality == "200" && (o.CustomerID == c.CustomerID)
select new { o.DueDate, c.CompanyName, c.ItemID, c.ItemName };

Hibernate

 //Query using Hibernate Query Language
String SQL_QUERY =" from Insurance as insurance where insurance.lngInsuranceId='1'";
Query query = session.createQuery(SQL_QUERY);

Desventajas de ORM

Como no va a ser todo cosas bonitas, enumero a continuación algunos puntos negativos a la hora de incluír ORM en tu proyecto:

  • Curva de aprendizaje: Las herramientas (o librerías) ORM suelen ser muy amplias, por lo que llegar a explotar su máximo rendimiento costará tiempo. Antes de incluír esta tecnología en tu proyecto, estudia y haz pruebas, sobre todo si el proyecto es entre mediano y grande. Si te metes en un proyecto con algo de complejidad sin conocer a fondo el sistema ORM, seguramente te estés metiendo en un problema.
  • Menor rendimiento: Está claro que tener una capa tan enorme entre tu código y el sistema de base de datos, ralentizará un poco la aplicación. Pongamos el ejemplo para una simple query, el sistema tendrá que: convertir la consulta al SQL del proveedor usado; enviar la consulta; leer registros, limpiarlos y convertirlos a objetos. Depende del encargado de proyecto decidir si este descenso en performance se verá compensado con la facilidad y velocidad de desarrollo.
  • Sistemas complejos: Normalmente la utilidad de ORM desciende con la mayor complejidad del sistema relacional. Es decir, si tienes una base de datos compleja, ORM también se te hará más complejo y perderás más tiempo adaptando tus clases que en un sistema de menor complejidad.

ORM en PHP

A continuación os pongo un listado de liberías ORM para incluír en tus proyectos PHP:

  • Doctrine: un framework que a pesar de ser joven, es muy completo. Una de sus características más importantes es la posibilidad de acceder a la base de datos a través de un lenguaje integrado llamado Doctrine Query Language (DQL). Tiene una documentación muy completa y sólo es compatible con PHP 5.
  • Propel: uno de los más antigüos y respaldados con frameworks como symfony. Tiene muy buena documentación y sólo es compatible con PHP 5
  • ADOdb Active Record: basado en la muy conocida librería de abstracción ADOdb. Funciona con PHP 4 y 5.

Si bien existen más sistemas, estos son los más utilizados actualmente.

Conclusión

Si todavía no estás usando ORM en tus proyectos, ya es hora de que te pongas las pilas :) .

No tengas miedo y creas que todo esto te complicará las consultas o que no vas a poder hacer ciertas cosas porque te limita, más bien es todo lo contrario. Decídeite por alguno de los frameworks citados, estúdialos y verás como es más fácil de lo que parece.

Espero que os haya gustado, nos vemos en el próximo artículo. ¡Un saludo!

¿Necesitas desarrollar un proyecto web o para móviles? ¡Estamos disponibles!

Visitar Cokidoo

Cokidoo, los creadores de Ontuts, desarrollamos proyectos tecnológicos centrados en redes sociales y aplicaciones web, aplicaciones móviles y consultoría web y bases de datos.

Somos jóvenes, inquietos, versátiles, apasionados por la innovación y enfocados en las nuevas tecnologías. Con Ontuts tratamos de compartir nuestro conocimiento adquirido en los distintos proyectos, ayudando a la comunidad y mostrando nuestra capacidad tecnológica.

Si necesitas un presupuesto sin compromiso, estamos disponibles, no dudes en contactar con nosotros.

Comentarios en esta publicación (10 comentarios)

¿Te ha gustado esta publicación? ¡Puedes compartir tu opinión con todos nosotros! Simplemente pincha aquí mismo.

Hace muy poco buscaba info sobre esto, de todas es un tema del que “cada maestrillo tiene su librillo”, casi nadie lo hace igual…

creo que el costo beneficio es muy grande y la calidad final se ve opacada, tal vez tendremos calidad y rapidez en el desarrollo, pero al cliente final lo que le importa es la velocidad de su aplicación, herramientas y técnicas de este tipo nos abstrae un tanto del motor de BD, pero si que le exige mucho a el y al sistema mismo, ya que algunas tal vez solo te interesa un campo de una celda, la herramienta obviamente creara todo un objeto cuando solo necesitas un dato, y asì muchos contra que le veo, desde el casi ataque masivo desde la herramienta al motor de BD, pero eso si que bonito queda codificado :D , aunque aveces la sentencias se complican un poco cuando se requieren de combinar muchas tablas.

Clothier

Exactamente esto mismo me lo planteé yo hace unos años. Una capa superior al SQL más cercana al usuario que permitiera montar consultas SQL de una forma muy dinámica. Y, como no, todo está inventado xD. Pero leyendo este tutorial y también lo que dice Wikipedia sobre los ORM llego a la misma conclusión que llegué cuando estuve a punto de lanzar a programar algo parecido: El mundo es demasiado complejo Y DEMASIADO DINAMICO para simplificarlo.

Me explico. Para tablas con enlaces simples y una sólida estructura referencial de proyecto académico, ok, aceptamos barco. Pero cuando tienes delante un proyecto vivo donde el cliente te pide nuevas funcionalidades continuamente y donde, por lo general, acabo uno defecándose en la base de datos: el ORM no sirve para nada.

Creo que esto cuajará cuando el SQL tradicional sea sustituido por las bases de datos orientadas a objetos. Sin embargo, hablamos de algo que todavía no está maduro. Es acojonante como el SQL lleva más de 40 años vivito y coleando y siendo usado en el 95% de los proyectos. En fin, tiempo al tiempo xD

P.D.: Gran página y grandes tutoriales. Se echa de menos una mayor frecuencia en la aparición de artículos y tutoriales.

Jorge Leguia

Me gustó el articulo. Se ve interesante aprender un ORM antes de aprender un Framework PHP mas robusto como Zend o Symfony.

Además algunas Software Factories en América Latina utilizan frameworks creados por ellos mismos a base de Smarty, Doctrine, jQuery y emplean mucho el patrón MVC.

Con respecto a las nuevas versiones del Doctrine(2.0), solo son compatibles con PHP 5.3 + .
A su vez esta versión del PHP 5.3.+ trae problemas con el PEAR (al descargar los paquetes)

Sería posible si puedes colgar un ejemplito utilizando Doctrine 2.0 y la configuración basica de un proyecto.

Saludos :)

Hola Jorge,

Queda anotada tu idea de ejemplo con Doctrine 2 :)

Gracias por tus comentarios!

franco

Un gran aporte, gracias sigue adelante

carloa aguirre

Hola hay algo q me confunde que diferencia hay entre ORM y ActiveRecord

Active Record es un patrón de desarrollo. Un ORM es una libreria o código que puede implementar o no dicho patrón.

Renzo Mendoza Prada

En el año 2009 fue que toqué este tema por primera vez, y realmente desde entonces me vengo desencantando más y más con los ORM. Probablemente a mis 31 años, con 13 años de desarrollo encima me he acostumbrado demasiado a las bases de datos relacionales… creo que el Modelo relacional efectivamente es bastante rígido y restrictivo, pero todos los problemas que genera han sido estudiados y resueltos, a los 3 o 4 años de trabajar con Informix, SQL Server, entre otros ya no me topaba con problemas nuevos… o por lo menos que otros ya solucionaron.

Sin embargo esa rigidez se ve compensada en el lenguaje de consultas, tan simple y versatil. Basado en conjuntos como decir peras + manzanas = peras con manzanas! … alcanzando resultados impresionantes, cada día el SQL me salva de un problema mayor que el anterior, en situaciones reales, sobre la marcha, y con una performance envidiable… muchas veces los usuarios (OJO, uno hace sistemas para USUARIOS) se sorprenden y me dicen :”que ya lo hizo? wow” a un trabajo que manualmente tomaría muchas horas. Si tengo que hacer una modificacion de procedimiento con DATOS DE NEGOCIO, no tengo que moverme mas que en el mismo origen de la data, el front end, cualquiera que sea… queda incólume sin enterarse de nada.

Yo he trabajado con Java EE 6, ahora en mi nuevo trabajo estoy utilizando MVC3 de .NET con Entity Framework, pero mi patrón predilecto siempre es el Transfer Object, ahora Entity Framework 4.5 acepta retorno de tipos complejos mapeados desde un procedimiento almacenado importado a ‘Funcion’, lo cual me alivia la vida enormemente. Igualmente siempre trato de provechar las bondades de las tecnologías centralizadas en servidor, tales como pooling Y nadie me reclama o se queja de por qué NO estoy usando un pinche ORM!

Mi recomendación final sería: Usen la tecnología que deseen, que les acomode. Los objetos son geniales, pero si su capa de datos se basa mayoritariamente en una base de datos relacional, no la dejen de lado porque estan cultivando una bomba de tiempo.

Un saludo!