Cómo ha se habrán dado la lata con los dos artículos anteriores sobre symfony, he tenido que tragarme más de un par de trasnochadas mejorando una aplicación en symfony que debo sacar sí o sí esta semana.

Después de leer casi completo EL LIBRO y partes de la API, ya casi, casi, puedo decir que entiendo como funciona el bicho.

En primer lugar, todavía me parece muy razonable la forma en la cual estructuraron la capa "Control". No es nada del otro mundo desarrollarlo (es cosa de hacer un par de includes bien puestos en función del URL), pero el sistema de ruteo con las URL no está mal. Casi drupaliano :)

Paso a responder al comentario de Blaxter:

Estimado Blaxter:

Muchas, pero muchísimas gracias con tus comentarios. Cuando empiezo a insultar a un enfoque de trabajo, mitad lo hago porque lo siento, mitad lo hago para los defensores lo defiendan con ardor.
Por tanto, me disculpo si te molestó lo poco juicioso de mi juicio sobre ORM. Ahora, leyendo nuevamente lo que escribí, la estupidez no está en el enfoque, sino al utilizarlo sin meditar . Realmente, creo que un enfoque mixto es lo mejor: ORM para trabajar de forma atómica y SQL crudo para los trabajos más complejos. Lo que pasa es que me disgusta profundamente cuando justifican en la documentación de symfony el uso de ORM por proteger los datos, cuando una query SQL bien hecha y con una buena protección frente a los datos de usuarios te ahorra memoria y líneas de código.

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.