Php y otras yerbas - symfony - Comentarios

Juas. Verdad. Al final,

clbustos — Tue, 27 May 2008 07:31:17 -0700

Juas. Verdad. Al final, cualquier pequeña modificación hace más cómodo escribir el select directo en HTML.

Se te han olvidado los

Blax — Tue, 27 May 2008 03:02:51 -0700

Se te han olvidado los helpers Object, object_select_tag() que a su vez si usas doctrine estará sobreescrito en el plugin para Doctrine, el cual a su vez para personalizarlo y usar internacionalización (cosa que necesito) tendrás que volver a sobreescribirlo!, pan comido! jaja </ironía>

Hola, que bien que estás

Leo Barrientos C. — Fri, 23 May 2008 15:38:11 -0700

Hola, que bien que estás con symfony yo lo uso hace un tiempo ya y como ORM uso Doctrine (no propel - entiendo que Doctrine es el ORM que va a continuar en el proyecto). Efectívamente usar un ORM es bastante útil, pero en Symfony viene muy "crudo" y a veces es inadecuado el mapeo si se trata de usar full orientado a objetos (Mal que mal Doctrine Query language trata de imitar Hibernate Query Language - pero le falta mucho ... i love hibernate/jpa) - por que no trae una buena separación de capas que le den lógica al desacople, en mi caso uso Managers y Daos que se utilizan Doctrine al màs puro estilo de Spring y appfuse.

Sobre Symfony en sí, me parece un buen producto para hacer software PHP, pero que le falta mucho para estar bien orientado a objetos - por las limitaciones mismas del lenguaje y por que hay cosas que son inaceptable como que aún trabajndo con objetos tengas que manipular los "relacion_id" [sin comentarios]; pero bueno es mejor que programarse cosas a pelo en ese sentido. Lo bueno es la parte del controlador y vista, muy fácil.

Sobre el tema de SQL, pues no sé yo mapeo clases y uso capas de persistencias, sólo uso sql cuando quiero hacer algo enfocado a la eficiencia y a cosas de BD puras. Me parece que el software no va de SQL, es una característica añadida que un modelo sea persistente.

Mis saludos cordiales y me gustó tu blog!.

Sin duda es MUY importante

Perejilillo desconocido — Mon, 12 May 2008 09:44:12 -0700

Sin duda es MUY importante conocer SQL.

es falso que sea exponencial, la consulta SQL cruda es MUCHISIMO mas rapida que el mapeador si no se sabe usar el mapeador. El problema real es que el mapeador (y los frameworks web en general) permiten con gran facilidad escribir codigo lento.

Mira esto por ejemplo: http://media.railscasts.com/videos/022_eager_loading.mov

Muchas gracias,

clbustos — Sun, 11 May 2008 10:40:26 -0700

Muchas gracias, Blaxter.
Como la aplicación en la que estoy trabajando ya está en symfony, estoy casado con el framework en general. Ahora, eso no quita que igual pueda tratar de usar doctrine como motor del modelo. Contaré como me va en el experimento.

IMHO, el que SQL sea más o

clbustos — Sun, 11 May 2008 10:38:41 -0700

IMHO, el que SQL sea más o menos horrible no quita que si debemos trabajar con ese esperpento para acceder a las bases de datos relacionales, tratemos de sacarle el máximo provecho. Si se hace una selección juiciosa del tipo de consultas que se harán, se ocupa una buena layer de abstracción que te permita tanto hacer querys "abstractas" como específicas al motor, en mi experiencia no hay problemas con las migraciones de bases de datos. Y no es más rápido, es MUCHISIMO más rápido, siendo exponencial a la complejidad de la consulta las ganancias en velocidad y, porque no decirlo, en producción y calidad de la mantención de los módulos.

Las faltas de SQL nos hacen olvidar que el modelo relacional es uno de los más poderosos inventos en la computación moderna, que ni las bases de datos jerárquicas, de redes y basadas en objetos han logrado superar. Aparte, si leen a Codd, se darán cuenta de la belleza de la teoría que está detrás del modelo.

escribir directamente SQL

Perejilillo desconocido — Sun, 11 May 2008 10:00:00 -0700

escribir directamente SQL tiene grandes desventajas:

- No puedes migrar entre motores de bases de datos o incluso entre versiones del mismo motor
- Muy dificil de mantener
- Tienes que conocer muy bien SQL
- SQL es horrible

Ventajas:
- Si lo haces bien, es mas rapido

El ActiveRecord de Rails es muy lento, symfony es una pesima copia de Rails, entonces ...

El sistema de Rutas y ActiveRecord de Rails es lo que hace lento, ha pruebas donde merb+datamapper es 70% mas rapido que rails.

http://datamapper.org/why.html
http://railsontherun.com/2008/4/10/rails-or-merb-what-s-best-for-you

Sin duda las soluciones

Blaxter — Sun, 11 May 2008 04:31:15 -0700

Sin duda las soluciones absolutas nunca son las correctas. Es decir, el usar un ORM luego no te impide simplemente pillar la conexión y ejecutar un SQL a mano (algo que para consultas complejas es lo mejor, sin duda). Simplemente lo que quería decir es que si tu acercamiento a un ORM ha sido principalmente con symfony, posiblemente tendrás muchos prejuicios y no te gustarán los ORM en general.

Básicamente lo digo porque después de estar usando otros framework (y ORMs), me ha tocado usar symfony y tenía opiniones bastante similares a las tuyas (pero sin generalizar). Si no lo has probado te recomiendo usar doctrine, aunque tiene como desventajas que todavía no tiene versión "final", y además muchos plugins son concretos para propel (el ORM de symfony) por lo que cierto riesgo existe para usarlo en proyectos reales.

Pregunta, ¿has usado

Blaxter — Sat, 10 May 2008 03:56:00 -0700

Pregunta, ¿has usado ActiveRecord de rails u otro ORM que implemente el patrón con ese mismo nombre?, el ORM de symfony es apestoso e incómodo de usar, pero decir que usar un ORM es estupidez... sin comentarios.

El sistema de generación de clases a partir de las tablas es, de nuevo, culpa del ORM (propel). ¿Por qué necesitamos generar tanto código si se podría ahorrar todo este paso usando el patrón Active record? Eso si, cuando sustituyes propel por doctrine, ganas bastante. El "código" que te genera es básicamente una traducción del yml a cuatro líneas de php (líneas que simplemente son una descripción del modelo, es decir, doctrine implementa active record)

La forma en que implementan MVC está muy orientada a construcción de componente, una filosofía muy cercana a JSF y más alejada del típico MVC visto en otros framework (como Zend Framework, RoR o Django). No está mal, pero, esta forma la veo mejor para lenguajes estáticos (java, .net) que para lenguajes dinámicos (php, ruby, python)

Bueno y ya lo de la configuración es la hostia. Totalmente de acuerdo en que apesta y mucho. No entiendo por qué narices, en un lenguaje dinámico, se usa tantísima configuración (me da igual que sea yml, xml que el formato que sea, toda configuración es pesada, aburrida y propensa a fallos).

En resumen, coincido en todo lo que dices pero matizando que todo lo que criticas sobre el ORM es debido a que el que se usa por defecto en symfony es obsoleto y pésimo. Y aunque no es un framework excesivamente malo, hay otras alternativas mucho mejores.