Estoy comenzando un nuevo proyecto con Symfony2 y no estoy seguro de qué ORM elegir. He oído algunas cosas malas sobre Doctrine2, especialmente cuando se trata de herencia y DQL. Parece que Propel ha vuelto de la muerte, pero, por otro lado, no hay garantía de que dure para siempre.¿Qué ORM usar con Symfony2?
¿Alguna opinión?
Puedo decir que Propel es el ORM más adecuado para usar con Symfony2. Funciona bien y no hay plan para detener las actividades en él. El proyecto Propel2 está en camino de ser mejor que Propel 1.6.x (que es realmente genial).
No dude en utilizar Propel, ¡muchos usuarios, incluidos Sensio Labs, lo están utilizando!
Aquí es el doc Propel para Symfony2: http://www.propelorm.org/documentation/#working_with_symfony2
Nota: Hay un tema relacionado en la pila de cambio: https://softwareengineering.stackexchange.com/questions/48760/should-i-choose-doctrine-2-or-propel-1-5-1-6-and-why/117078#117078
Algunos puntos que se olvidaron:
Algunos puntos Me gusta en el Doctrine2:
El problema no es sobre Doctrine DBAL pero más sobre Doctrine ORM. Y Propel2 está en camino de mejorar todo el código de Propel 1.6.x.
Ah, y he usado Doctrine2 durante mucho tiempo;)
Esa pregunta de http://programmers.stackexchange.com trata de elegir ORM sin ninguna relación con el marco. Justo sobre elegir ORM como una herramienta independiente, según tengo entendido. –
Está bastante relacionado ya que Symfony2 es agnóstico. Como dije, los paquetes casi oficiales también son agnósticos y no es un problema usar Doctrine ORM, ODM, Propel, Mandango, etc. –
Probablemente deba revelar su afiliación con Propel en su publicación. – Problematic
te puedo decir que es el ORM Propel más adecuado para su uso con Symfony2 que debería estar en desacuerdo. Doctrine2 es nativo ORM para Symfony. Está contenido en la distribución estándar de Symfony disponible aquí: http://symfony.com/download
La documentación de Symfony describe que se trabaja principalmente con Doctrine, no con Propel. Por lo tanto, no creo que la elección de Propel sea demasiado obvia. Creo que deberías realmente pesar las consecuencias. Preferiría Doctrine.
Aquí está una lista de opciones, con el apoyo de Propel paquete: http://www.propelorm.org/cookbook/symfony2/working-with-symfony2.html
Nada es nativo y Doctrine se eliminará del núcleo de Symfony2 (en la versión 2.1), solo lea la última publicación del blog de Fabien Potencier. –
@William DURAND ¿A qué blog te refieres? De todos modos, si incluso esto es cierto, por ahora (2.x rama) Doctrine es seguramente nativa. Y la documentación oficial trata sobre Doctrine, no sobre cualquier otro ORM. Además, el autor de Doctrine, Jonathan H. Wage, trabajó para Sensio Labs durante algún tiempo. –
Este: http://fabien.potencier.org/article/49/what-is-symfony2 El documento no trata de Doctrine, a excepción de un capítulo documentado también para Propel. Los grandes paquetes son agnósticos y funcionan con Propel como un amuleto. Sé que Jonathan trabajó para SL. ¿Cambiarás de opinión si me contratan? No lo creo;) No digo que Doctrine2 no sea adecuado para Symfony2, pero es difícil de usar en la vida real. Los usos básicos están bien, pero si quieres hacer más cosas, es bastante difícil. –
Mi elección personal es Doctrina 2 por varias razones:
Conceptualmente, es muy fácil de entender. Trabajar con entidades y el administrador de la entidad es simple. Me encanta cómo las entidades no necesitan extender ninguna clase de modelo base (como en Doctrine 1).
Es tipo de el ORM estándar para Symfony2 en este momento. Si bien Symfony2 no lo respalda oficialmente, es lo que la mayoría de la gente está usando y, por lo tanto, existe una gran cantidad de información en línea. El valor de esto es tremendo.
usted menciona que usted ha escuchado "cosas malas sobre Doctrine2" - es importante que se den cuenta sin ORM va a ser perfecto. Me he encontrado con algunos problemas, pero siempre que pienses de forma creativa, puedes encontrar una solución. A veces esa solución significa escribir SQL sin formato, sin importar lo que puedan decir los puristas de ORM. No me he encontrado en ninguna situación en la que lamentara usar Doctrine 2.
Pasé mucho tiempo mirando a Propel, pero simplemente no me gustó cómo funcionó. Eso no quiere decir que es una biblioteca mal programada, pero para mí personalmente no era una buena opción. Pero dado que cada desarrollador es diferente, el mejor consejo que puedo ofrecer es que consulte los ejemplos de documentación y uso para ambas bibliotecas. Como usted va a usarlo, y no nosotros, debe elegir la biblioteca de la que cree que se beneficiará más.
Bueno ... No sé dónde vio el DataMapper DP es más fácil que el enfoque ActiveRecord. Estoy de acuerdo en que las entidades son simples pero demasiado restrictivas. El problema es que cuando quieres construir cosas reales, tienes que entender la complejidad detrás de D2 y cómo funciona, lo cual no es fácil. ActiveRecord es bastante simple, incluso si quieres construir cosas complejas. –
Estoy familiarizado con ActiveRecord de Doctrine 1. Estoy de acuerdo en que es fácil de usar, pero hay muchos casos en los que no es tan eficiente como el patrón de mapeo de datos. –
Dame un caso de uso donde DataMapper es más eficiente que AR? ¿Intentó un conjunto/árbol anidado, por ejemplo? –
Recuerdo cuando aprendí s1, vi algunas alternativas enumeradas en los tuts, y adopté un par. Lo lamento, b/c si la comunidad usa, p. Doctrine, todos los ejemplos de blog y comentarios SO girarán en torno a Doctrine. Así que incluso si Propel fuera más adecuado (no lo sé), D sigue siendo una mejor opción pragmática. – yitznewton