PHP ORMs: Doctrina vs. Propel


126

Estoy comenzando un nuevo proyecto con Symfony que se integra fácilmente con Doctrine y Propel , pero, por supuesto, tengo que tomar una decisión ... Me preguntaba si las personas más experimentadas tienen ventajas y desventajas generales para seguir adelante. cualquiera de estos dos?

Muchas gracias.

EDITAR: Gracias por todas las respuestas, cosas útiles. No hay una respuesta verdaderamente correcta a esta pregunta, así que marcaré como aprobada la que obtuvo los votos más populares.


55
Chicos, ¿hay alguna respuesta actualizada? Al ver que así está desactualizado
Qiniso

Respuestas:


76

Yo iría con Doctrine. Me parece que es un proyecto mucho más activo y que es el ORM predeterminado para Symfony, está mejor soportado (aunque oficialmente los ORM se consideran iguales).

Además, me gusta más la forma en que trabaja con consultas (DQL en lugar de Criterios):

<?php
// Propel
$c = new Criteria();
$c->add(ExamplePeer::ID, 20);
$items = ExamplePeer::doSelectJoinFoobar($c);

// Doctrine
$items = Doctrine_Query::create()
       ->from('Example e')
       ->leftJoin('e.Foobar')
       ->where('e.id = ?', 20)
       ->execute();
?>

(La implementación de Doctrine es mucho más intuitiva para mí).

Además, realmente prefiero la forma en que manejas las relaciones en Doctrine.

Creo que vale la pena leer esta página de la documentación de Doctrine: http://www.doctrine-project.org/documentation/manual/1_2/en/introduction:doctrine-explained

En resumen: si estuviera comenzando un nuevo proyecto o tuviera que elegir entre aprender Doctrine y Propel, iría a Doctrine cualquier día.


42
En Propel 1.5, esta consulta también se puede escribir como Example_Query :: create () -> joinWith ('FooBar') -> filterId (20) -> find () (o findPK (20) después de joinWith if Id es su principal llave). Como puede ver, toma la buena sintaxis de Doctrine y agrega un poco más. El lanzamiento está previsto para finales del primer trimestre de 2010, pero ahora puede probarlo en sus proyectos de Symfony.
Jan Fabry

Buena entrada, no lo sabía :-)
phidah

9
La implementación de la doctrina me parece mucho más compleja. Obtener Entidad gestionar get repositorio ... esto y aquello
SoWhat

1
la doctrina ha terminado de complicar las cosas ... solo la tormenta es el camino a seguir
Geomorillo

40

Soy parcial, ya que ayudo un poco en el próximo lanzamiento de Propel, pero debes considerar que Propel fue el primer ORM disponible, luego se retrasó un poco cuando se creó Doctrine, pero ahora tiene un desarrollo activo nuevamente. Symfony 1.3 / 1.4 viene con Propel 1.4, donde la mayoría de las comparaciones se detienen en Propel 1.3. Además, la próxima versión de Propel (1.5) contendrá muchas mejoras, especialmente en la creación de sus Criterios (resultando en menos código para que usted escriba).

Me gusta Propel porque parece ser menos complejo que Doctrine: la mayoría del código está en las pocas clases generadas, mientras que Doctrine ha dividido la funcionalidad en muchas clases. Me gusta tener una buena comprensión de las bibliotecas que estoy usando (no demasiada "magia"), pero por supuesto, tengo más experiencia con Propel, por lo que quizás Doctrine no sea tan complicado detrás de escena. Algunos dicen que Propel es más rápido, pero debe verificarlo usted mismo y considerar si esto supera otras diferencias.

Quizás también debería considerar la disponibilidad de los complementos de Symfony para los diferentes marcos. Creo que Propel tiene una ventaja aquí, pero no sé cuántos de los complementos enumerados todavía están actualizados con la última versión de Symfony.


44
Las nuevas mejoras de consulta en Propel 1.5 son realmente agradables.
Tom

23

Todo se reduce a la preferencia personal. Uso Propel porque (entre otras cosas) me gusta el hecho de que todo tiene su propio método concreto de captador y definidor. En Doctrina, este no es el caso.

Impulsar:

$person->setName('Derek');
echo $person->getName();

Doctrina:

$person->name = 'Derek';
echo $person->name;

La razón por la que me gusta tener getters y setters es que puedo poner todo tipo de lógica en ellos, si es necesario. Pero esa es solo mi preferencia personal.

También debo agregar que, aunque Propel se movía lentamente en el pasado, ahora está en desarrollo activo nuevamente. Ha lanzado varias versiones nuevas en los últimos meses. La versión más reciente de Propel incluye una "interfaz de consulta fluida" similar a la de Doctrine , por lo que ya no tiene que usar Criterios si no lo desea.


77
en Doctrine puede anular establecedores y captadores para cada propiedad y también tener una lógica personalizada (vea doctrine-project.org/documentation/manual/1_2/en/… - busque ATTR_AUTO_ACCESSOR_OVERRIDE para llegar a la sección correspondiente)
Marek Karbarz

Eso se ve bien, pero aún configura la propiedad llamando: $ x-> propname = 'abc'; Esto es problemático porque no parece soportar pasar múltiples parámetros.
lo_fye

20

Cabe señalar que Doctrine 2 está actualmente en desarrollo lanzado [ed] y funciona casi completamente diferente de la versión estable actual de Doctrine 1. Se basa en el patrón Data Mapper en lugar de Active Record, y utiliza un 'administrador de entidad' para manejar la persistencia lógica. Cuando se lance, se parecerá más a la Hibernación de Java (Doctrine 1 se parece más a ActiveRecord de Rails).

He estado desarrollando con la versión alfa de Doctrine 2, y debo decir que está muy por encima de Doctrine 1 (solo mi opinión, y nunca he usado Propel). Es muy probable que la comunidad de Doctrine avance hacia ella cuando se lance.

Le recomiendo que consulte Doctrine, pero si prefiere el estilo Active Record que Propel y Doctrine usan ahora, es posible que desee seguir con Propel.


44
Recientemente se lanzó una versión estable de Doctrine 2. doctrine-project.org/blog/doctrine2-released
Trevor Allred el

5

Las dos referencias están un poco desactualizadas, por lo que, sin embargo, cubre algunas generalidades, básicamente tendría que evaluar su experiencia con el marco como tal, un inconveniente importante de la doctrina es la incapacidad de tener un IDE que le permita codificar automáticamente en ese impulso. un ganador, las curvas de aprendizaje de la propulsión y la doctrina son muy diferentes, es más fácil impulsar, si su proyecto necesitará administrar un modelo de datos complejo que utiliza la doctrina, si desea trabajar rápidamente con un ORM que esté mejor documentado y encuentre más apoyo en Propel Usos de Internet, es mucho más maduro y creo que es el más utilizado.

http://propel.posterous.com/propel-141-is-out


En el mundo de Symfony, parece que Doctrine es definitivamente el más utilizado, especialmente para proyectos más nuevos. Por supuesto, hay muchos proyectos de sf 1.0 que todavía usan Propel porque Doctrine no estaba disponible para Symfony hasta 1.1.
phidah

5

Sugeriría usar propel 1.6, que es mejor para la función de autocompletado de IDE.


26
-1 La finalización automática de un IDE no debería ser el motivo de una elección técnica
Clement Herreman

14
@ClementHerreman Estoy de acuerdo en que no debería ser el criterio, pero creo que lo productivo que se puede ser con una tecnología en particular debería ser una razón para elegirla. Y con el debido respeto, por lo tanto, no estoy de acuerdo con su voto negativo ... independientemente de si está de acuerdo con la respuesta, no es "incorrecta" (¿o sí?), Y es de alguna utilidad (a menos que sea incorrecta, en cuyo caso , deberías decir esto).
Sepster

2
En mi opinión, si su productividad mejora más mediante el autocompletado en lugar de la calidad del software, la intuición y la coherencia, está sucediendo algo extraño. Ver codinghorror.com/blog/2009/01/… . Pero tienes razón, en algún momento esta respuesta no es incorrecta , simplemente no es lo suficientemente buena, tal vez incluso no sea buena.
Clement Herreman

1
@ClementHerreman, si no es útil, no lo uses más;), +1
amd

¿Hay alguna respuesta actualizada a esto? Esto está muy desactualizado.
Qiniso

2

No soy un usuario de PHP 5 sin marco ORM, pero aquí hay algunas buenas publicaciones de comparación (en caso de que aún no las haya visto):

http://codeutopia.net/blog/2009/05/16/doctrine-vs-propel-2009-update/

http://trac.symfony-project.org/wiki/ComparingPropelAndDoctrine

Ambos son los favoritos de Doctrine como una nueva generación de ORM para Symfony.


1
Para el registro, esta comparación está totalmente desactualizada: la versión actual de Propel usa PDO, sí admite relaciones de muchos a muchos y tiene una excelente documentación. También vale la pena considerarlo: algunos de nosotros preferimos el estilo de consulta detallado del generador de criterios sobre los lenguajes de consulta propietarios como DQL; tiene soporte IDE y es una clase, por lo que puede extenderlo. Todavía estoy tratando de elegir, pero veo muchas ventajas para Propel sobre Doctrine, si no te importa la generación de código estático y puedes ver las ventajas del código PHP "real" en lugar del lenguaje de consulta propietario , que son solo cadenas para un IDE.
mindplay.dk

2

Después de usar ambos durante varios años, prefiero Propel 2 a Doctrine simplemente en función de cómo construye su lógica de consulta. Doctrine es tan profunda como puede ser y manejar muchos aspectos de ella coinciden con ese nivel de profundidad. Propel creo que tiene una forma más fluida y orientada a objetos de construir y administrar las interacciones de consulta.

Para mí, esto condujo a menos código en el modelo y más estructuras en torno a cómo la lógica puede / será procesada. Esto resultó en la construcción de muchas interacciones como funcionalidad común. (Después de todo, el 90% de lo que harás con una base de datos solo será un cierto grado de operación grosera).

Al final, ambos son potentes, manejables y harán el trabajo. Mis proyectos personales e intereses usan Propel ORM 2 y proyectos futuros, si todavía están escritos en PHP, seguirán ese camino.

He estado usando ambos a diario durante los últimos 3-4 años.


1

Sugeriría usar el complemento DbFinder . Este es en realidad un complemento muy poderoso que admite ambos, y es bastante bueno. De hecho, me gusta usarlo mejor que cualquiera.


@ Mike: gracias, no sabía sobre el complemento, pero parece que solo admite hasta Sf1.2. Terminé yendo con Doctrine al final, siento que fue la elección correcta, aunque es necesario escribir SQL directo para las cosas más complejas.
Tom

-2

Si no me equivoco, ambos ORM usan un esquema basado en XML, y crear esta definición de esquema es bastante engorroso. Si necesita un esquema simple basado en PHP con estilo fluido. Puede probar LazyRecord https://github.com/c9s/LazyRecord, es compatible con la migración automática y los generadores de scripts de actualización / degradación. Y todos los archivos de clase se generan estáticamente sin costo de tiempo de ejecución.

Al usar nuestro sitio, usted reconoce que ha leído y comprende nuestra Política de Cookies y Política de Privacidad.
Licensed under cc by-sa 3.0 with attribution required.