Cita:
Iniciado por NSD 
No he usado Propel en un proyecto real por lo que no estoy calificado como para decir realmente cuales son sus limitaciones, al ser parte de un ORM, también es difícil de saber (sin ponerse a usarlo y a probar, me refiero) si los que a simple vista lo parecen, son realmente limitantes.
La impresión que me lleve al leer la documentación (que por cierto, la leí semi-completa hace un tiempo, no solo este caso particular) es que tiene muchas cosas para hacer poco, y que las tareas mundanas de todos los días se vuelven complejas (por ejemplo este caso de hacer un par de joins) a cambio de simplificar otras tareas que rara vez son requeridas.
No es asi, es lo mismo que con cualquier otro QB de los que mencionas mas abajo solo cambia como están diseñados y sus interfaces.
Cita: Un query builder que me gusto desde el punto de vista de la usabilidad es el de
Laravel, sumamente elegante y que no complica las cosas mas de lo estrictamente necesario.
Otro que es un poco mas complejo pero interesante es el de
Zend, si bien es mas complejo que el de Laravel, también es mas extensible que este.
Doctrine por su parte también tiene uno interesante aunque no tan completo como los anteriores.
Al lado de estos, Propel, (desde mi punto de vista) es mas limitado.
De los que mencionas el unico con el que no e trabajado es con el de Zend y reduciendo las cosas a sus QB con todos puedes hacer lo mismo mas prestaciones propias de cada diseño como en el caso de Laravel con su interfaz fluida.
Cita: No obstante, todos los mencionados previamente, tienen 3 grandes problemas:
1) Dependencia del entorno:
Cada uno esta pensado para integrarse perfectamente con su Framework o con componentes de este, pero al sacarlo de allí y querer usarlo de forma aislada presentan inconvenientes o molestias que obligan a adaptarse a su forma de trabajar.
Falso, pueden ser usados de forma independiente, algunos usan cosas de terceros como Propel pero son facilidades. Tampoco te obligan puede usarlos a diferente nivel de abstracción segun te convenga, las molestias están en el nivel de preparación del programador.
Cita: 2) Eficiencia y organización:
En general, cada QB son decenas de archivos, decenas de clases, cientos de métodos, muchas interfaces, muchas lineas de código, etc que terminan por lograr, que solo el que las programo las entienda y que un simple SELECT demore mucho mas de lo que debería simplemente por el nivel de abstracción del modelo.
Son eficientes y están perfectamente organizados y ese centenar de archivos molestos tienen un razón de ser. la demora es es algo que no tiene menor problema todos los ORM te permiten trabajar a diferentes niveles de abstracción; asi que si necesitas mejores tiempos estos QB son suficientemente felxibles para hacer lo que necesites.
Cita: 3) Ineficiencia en sentencias preparadas:
Ninguno de estos query-builder saca provecho de las sentencias preparadas. Las usan como medio de seguridad pero no de optimizacion.
Así, si yo quiero realizar 20 consultas, termino preparando 20 sentencias en vez de reutilizar las anteriores.
[/code]
Falso, si optimizan sus consultas de forma diferente cuentan con una forma de construir la gramatica que soporta un RDBM especifico y tener la consulta preparada para su reutilización.
Vuelvo al punto no es el ORM o el QB si no la mente de quien lo usa lo que crea una ventaja o una limitación.
Cita: Personalmente prefiero usar DBAL simples, de un solo archivo, una única clase, menos de 1500 lineas de código incluyendo documentación. Por
ejemplo esta que es la que actualmente me encuentro desarrollando, donde intento implementar de forma minimalista, los métodos y características mas útiles de los QB antes mencionados y de muchos otros mas pequeños que son muy precarios pero que tienen una idea interesante dentro.
Te felicito y es valida
Es valido tu punto de vista, cada quien decide la forma de abordar y solucionar un problema.