Primeras impresiones sobre symfony
Uno de los frameworks más conocidos para PHP, especialmente por aquellos que gustan de Ruby on Rails, es symfony. Siempre he mirado con desconfianza esos frameworks que comienzan señalando que son fáciles de instalar, con poco uso de memoria, fáciles de entender y, a la vez, son 'enterprise ready', tipo ROR. Miren el acerca que y me entenderán. Aparte, si suman a esto el uso sin crítica de MVC, de miles de archivos de configuración basados en YAML y el uso descarado de mapeo en objetos de una base de datos relacional, entenderán que no me haya querido acercar so pena de colapso.
Como no hay que escupir al cielo, porque se te devuelve, tuve que meterme igual por culpa de mi pega. Debiendo administrar un sistema con más de 40 tablas e igual cantidad de módulos de trabajo, no tuve más que dejar de lado mis prejuicios y tratar de entender lo más rápido posible como funcionaba el sistema. Mis conclusiones tras dos días de trabajo a toda máquina son las siguientes:
- El sistema de generación de clases a partir de las tablas me gustó. Me agrado el que se creen automáticamente las clases en archivos separados a los de las clases que uno puede manipular, por sobrecarga.
- El uso de ORM a destajo es una estupidez si no se ocupa cómo y cuándo corresponde. Si bien puede servir para consultar un dato particular, no entiendo el sentido de armar 50 líneas de código para algo que en una consulta SQL con un par de JOIN te lo soluciona en 2. Mejor usar Creole a secas y uno se ahorra bastantes problemas. Hubiera preferido adodb, pero bueno....
- La lógica de los "controles" y las "vistas" es muy buena. Con sorpresa, me di cuenta que era casi exactamente lo mismo que yo había hecho en un sistema grande que armé hace un par de años, pero más ordenado.
- Las configuraciones con múltiples archivos .ini y yaml apesta. Es una manía que viene de JAVA con sus configuraciones eternas en XML. Mucho mejor sería tener sencillos archivos php bien comentados. Aparte, el sistema pierde tiempo generando php a partir de esas configuraciones, aunque sean puestas en cache
Conclusión provisoria: symfony puede ser una buena alternativa para generar rápidamente un sistema funcional, a partir de la pura definición de la base de datos. Me parece especialmente apropiado para desarrollar de forma muy rápida sistemas de intranet que cuenten con formularios relativamente simples, reemplazando a lo que tradicionalmente se haría con Access. No recomiendo para nada limitarse a las funciones de ORM y, urgentemente, veré como ahorrarme toda la paja molida para tocar directamente el SQL, con las debidas precauciones para evitar inyección de datos.
- 1041 lecturas
Buscar
Publicidad
Inicio de sesión
Comentarios recientes
- simplemente muy bien
hace 12 horas 32 mins - espero poder
hace 2 días 8 horas - No me funciona, tendrían un
hace 3 días 3 horas - $a = ""; $m = ""; $d = "";
hace 6 días 7 horas - Lo que tenes que hacer es un
hace 6 días 7 horas - No entendí mucho la
hace 1 semana 4 días - como puedo saber si tengo un
hace 1 semana 4 días - Buenas Tardes,
Estoy creando
hace 1 semana 6 días - Descárgalo de
hace 2 semanas 1 día - necesito hacer un proyecto
hace 2 semanas 1 día
Referencias
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.
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
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.
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
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!.
Enviar un comentario nuevo