Alternativas a Doctrine para las aplicaciones Symfony2

Doctrine es el ORM más utilizado en las aplicaciones Symfony2. Su principal ventaja es una integración totalmente transparente con el framework, lo que simplifica muchas de sus tareas. El problema es que cada vez más programadores están hartos de Doctrine.

Las principales quejas hacia Doctrine son su lentitud, su mala documentación, su poca actividad de desarrollo, su excesiva complejidad y lo difícil que es encajarlo en los proyectos: si tu proyecto es pequeño, Doctrine se queda muy grande; y si tu proyecto es grande, lo primero que sueles hacer es prescindir de Doctrine.

Así que a raíz de esta conversación en Twitter con Asier Marqués, Ricard Clau y Antonio García, he recopilado algunos proyectos alternativos para PHP:

  • Propel ORM, fue el ORM más popular de PHP hace varios años, pero ahora es un proyecto moribundo. Lo único bueno es que tiene cierta integración con Symfony.
  • EloquentORM es el ORM que utiliza el framework Laravel.
  • Idiorm y Paris, los dos proyectos forman un toolkit para manejar bases de datos. Su principal ventaja es que son muy ligeros, por lo que se pueden considerar micro ORM.
  • NotORM, se autodefine como micro ORM con un buen rendimiento y un bajo consumo de memoria.
  • RedBean PHP, ORM que promete "cero configuración" debido a la obligación de usar convenciones muy estrictas.

Curiosamente, en esta lista de ORM alternativos todos utilizan el patrón Active Record (el mismo que usa por ejemplo RubyOnRails), salvo Idiorm, que utiliza el mismo patrón Data Mapper que Doctrine.

Aunque los dos patrones tienen sus ventajas y desventajas, en general se considera que el patrón Data Mapper es mejor para el desarrollo de aplicaciones. La única excepción clara sería al desarrollar aplicaciones sencillas de tipo CRUD, donde el patrón Active Record es mucho más cómodo de utilizar.

Y en tu caso ¿cuál es tu experiencia con Doctrine? ¿Te estás planteando cambiar de ORM? ¿Has probado otros ORM? ¿Te han convencido o te han decepcionado?

Comentarios

  1. Como se suele decir, no hay malas tecnologías, hay malas implementaciones. Cada vez se tratan NoSQLs como tecnologías de acceso en request (como redis, solr o elasticsearch), por lo que no creo que haya muchos proyectos (de tamaño medio) que realmente lleguen a tener problemas con un ORM como Doctrine por temas de ineficiencia (insisto, siempre y cuando esté todo bien configurado y optimizado. Hacer un flush sin saber qué es un flush es "NO" saber trabajar con Doctrine, y en este caso quejarse no es muy adecuado...).

    Nosotros trabajamos con Doctrine, y en Elcodi nos hemos casado con él. Cuando trabajas con Symfony hay una tendencia real en trabajar con Doctrine (supongo que por nada más que en la standard de Symfony ya viene preconfigurado así), y realmente no hay problema. Hay muchos proyectos encima de Doctrine y si investigas acabas encontrando todo lo que necesitas (esto no quita que si, la documentación da mucho que desear, pero ya se sabe... unos buenos PR no hacen daño a nadie ^^ )

    Seguro habrá más alternativas distintas (mejores o peores para según que caso, que solución y que proyecto) pero me gusta ver alternativas. A más opciones para el desarrollador, más opciones de tener algo más a medida.

    Gracias por el buen post.

    Marc Morera el 22 de julio de 2014, 17:39:00

  2. Totalmente de acuerdo con Marc Morera.

    No voy a defender que el rendimiento de Doctrine sea perfecto, pero cada vez que he visto problemas de rendimiento con Doctrine la culpa era del programador y no de la tecnología. No habré visto veces usar el find (el genérico del EntityRepository) para mostrar 2 datos en una plantilla o no entender ni usar los tipos de hidratación.

    No digo que sea suficiente para todos los proyectos, pero lo que esta claro es que mal usado puede ser una bomba que este matando tu aplicación.

    Dicho esto, habrá que mirar un poquito esos ORM ;).

    Saludos!

    Daniel Gallardo el 23 de julio de 2014, 8:10:56

  3. Hola Daniel, ¿a que te refieres con mostrar 2 datos? te refieres a ¿dos columnas de una tabla de diez columnas por ejemplo? ¿es más eficaz hacer una consulta que el usar el find?, evidentemente por tamaño de datos si ya que sera menos cuanto menos datos obtengas, pero ¿hay alguna razón más por la que sea más lento?

    Disculpa mi ignorancia pero no soy muy espabilado jaja

    Alberto Vioque Muñoz el 23 de julio de 2014, 12:24:53

  4. Si Alberto, cuando haces un "find", Doctrine, por defecto, te saca e hidrata todos los datos de esa entidad (relaciones incluidas), lógicamente eso es mucho mas lento y pesado que preguntar e hidratar solo los 2 datos que vas a mostrar.

    http://docs.doctrine-project.org/en/latest/reference/partial-objects.html

    Al igual que es mucho mas rápido hidratarlo como array que como objeto.

    Los más expertos son capaces de decirte muchísimas mas cosas de este tipo que hacen que tu aplicación vaya más lenta, y estos ejemplos, no son culpa de Doctrine, son culpa del programador.

    Daniel Gallardo el 23 de julio de 2014, 15:30:34

  5. Muchas gracias Daniel, entonces se podría decir que cuando queremos usarlo solo para mostrar datos aunque sean todas las columnas es mejor hacerlo como array, por el rendimiento, pero cuando queremos trabajar con esos datos es mejor usar objetos ¿no?

    Alberto Vioque Muñoz el 23 de julio de 2014, 16:17:13

  6. Hola,

    Estoy con Marc Morera, habría que ver cuanta "culpa" tiene la tecnología en sí, y cuanta el propio uso de la misma por parte del desarrollador. Es cierto también, que la documentación tiene mucho que mejorar.

    En PHP venimos de hacer siempre las cosas con Active Record (ie: Propel), con la entrada de Doctrine 2 (Data Mapper) y Symfony2, la gente ha empezado a usarlo y probablemente, no han acabado de entender el cambio, y sigan usándolo como un Active Record, viendo asociaciones 1 a 1 entre clases y tablas de la base de datos, o entre registros e instancias de los objetos.

    Desde el punto de vista del rendimiento, pues no ha sido algo de lo que me haya tenido que preocupar en exceso. Dejo un par de enlaces al respecto:

    Saludos!

    David Castelló el 25 de julio de 2014, 9:19:34

  7. Por vuestros comentarios se puede decir que dais la razón a Javier en su post. Doctrine es un mal ORM salvo para aquellos que saben evitar sus puntos flojos. Cosa que se podía decir de todos los ORM? Así que quizás los que no dominemos tanto deberíamos optar por los que aconseja Javier.

    Muchas gracias por el artículo y por los comentarios, desconocía todo lo que habéis comentado.

    Iago Sanjurjo el 25 de julio de 2014, 20:51:54

  8. Iago, no creo que le estemos dando o quitando la razón a nadie. Javier propone muy amablemente alternativas (cosa que creo que todos apoyamos), lo único que decimos es que es muy fácil decir que una tecnología es buena o mala sin tener una correcta perspectiva. Creo que todos estamos de acuerdo en que es el programador el dueño de su trabajo, encargado de decidir si sus herramientas son válidas, y es el programador también el encargado de aprender dichas herramientas.

    Dicho esto, creo que Doctrine es una buena herramienta si conoces bien su funcionamiento, y no por su complejidad debe ser ignorada por la gente, en busca siempre de la tecnología más fácil o con una curva de aprendizage más baja ;)

    PD: Daniel Gallardo, ojo con los partials. Introducir partials en Doctrine es peligroso, y mas cuando el proyecto no está documentado. A mi no me gustan ya que introduce muchas "dudas" en el desarrollo en el momento de ver si un objeto es partial o no... El tema de la hidratación en cambio si que es importante.

    Si queréis ver un poco más de doctrine, hace unos dias Albert Casademonet hizo en Barcelona una buena presentación sobre el ORM.

    http://phpbarcelona.org/eventos/php-barcelona-monthly-talks-persistencia-con-doctrine

    Marc Morera el 27 de julio de 2014, 14:35:59

  9. Cierto Marc, mi comentario diciendo que Doctrine es un mal ORM es erróneo. Es un buen ORM, pero como todos los demás tienes sus pros y contras. Por eso el post y vuestros comentarios son tan didácticos.

    Iago Sanjurjo el 29 de julio de 2014, 8:42:39

  10. El asunto es muy sencillo. Hay que ir con la evolucion y lo que apunta al futuro. Desde Php 5.5 Opcache es el mejor acelerador. Pero Doctrine se quedo solo manejadores para Apc, Memcache, Xcache, etc y no incluye para Opcache. Lei que Opcache supera a los demas en un 20%. Necesitamos un ORM que acepte Opcache, si queremos que symfony3 o symfony4 sea con php7...es decir...a la velocidad que todo el mundo ira en epocas de php7 ! La pregunta debe entonces incluir tambien esto de la velocidad, hacerlo bien...y rapido! Es el pedido de hoy

    Nelson Sheyim Atamashi Restrepo Jurado el 12 de septiembre de 2015, 16:40:36

  11. ah...olvidaba decirlo, estoy con Javier...buscando una alternativa a Doctrine!

    Nelson Sheyim Atamashi Restrepo Jurado el 12 de septiembre de 2015, 16:43:25

Este artículo ya no permite añadir más comentarios.
¿Por qué? Los artículos cierran sus comentarios automáticamente unos meses después de su publicación para asegurar que estos sigan siendo relevantes.

Publicada el

22 de julio de 2014

Proyectos Symfony destacados

La plataforma de eCommerce 100% Symfony que rivaliza con Magento y PrestaShop. Ver más

Síguenos en @symfony_es para acceder a las últimas noticias.