Symfony: El mejor framework de PHP

Primero que nada Symfony, no es un framework MVC, Symfony es un framework Full stack. En éste artículo no voy a debatir porque Laravel no es el mejor framework de php. Sin embargo, considero que Laravel tiene un lugar muy especial en el mundo de PHP.

Sin más preámbulo, a continuación mis puntos de porque Symfony es el mejor framework de PHP

1. Symfony es un framework full stack increíblemente rápido.

Una de las principales razones por las cuales prefiero frameworks full stack en lugar de micro frameworks es porque los frameworks full stack como Symfony reducen el tiempo de crear una aplicación considerablemente.

Por ejemplo la versión completa de Symfony viene con componentes que se encargan de administrar las rutas de tu aplicación, ORMs, Migraciones de bases de datos, validación de formularios, administración de sesiones, autorización y autenticación, serializadores, procesadores de correo electrónico, barra de depuración e interfaz gráfica para analizar el desempeño de la aplicación.

A pesar de que Symfony vine bastante completo, e incluso "pesado" bajo algunos estándares. Symfony, sin ninguna capa de caché, distribuidores de carga, o técnicas avanzadas, es capaz de manejar por sí solo hasta 700 peticiones por segundo con un tiempo de respuesta promedio de 30 milisegundos. Si te pones a analizar ese número te daras cuenta que estás hablando que Symfony, por si solo, es capaz de servir 60 millones de peticiones diarias.

2. Desarrollar una aplicación compleja en Symfony es muy, muy, muy fácil.

He de admitir que la primera vez que tuve que mantener un proyecto escrito en Symfony, me encontraba bastante frustrado por tener que utilizar un framework que en mi mente iba a estar lleno de convenciones como Zend, y tenía que aprender nuevas nomenclatura y series de convenciones.

Sin embargo, mi sorpresa fue que Symfony rápidamente se convirtió en mi framework de PHP favorito, y vaya que he utilizado un sin fin de frameworks, y no digo que alguna cosa es mi favorita ligeramente.

Symfony viene con convenciones y nomenclaturas, sin embargo es lo suficientemente flexible que si no te quieres apegar a sus convenciones, simplemente puedes ignorarlas y desarrollar tu aplicación como mejor te plazca, sin que Symfony se interponga en tu camino.

No importa si quieres programar una aplicación monolítica, una aplicación que utilize SOA o micro-servicios. Con Symfony puedes hacer las tres cosas muy fácilmente, sin necesidad de hacks.

Necesitas soportar autenticación por nombre de usuario y contraseña, autenticación por OAuth, SSO, o todas al mismo tiempo? Symfony te permite hacer absolutamente eso dado que separa la autenticación y la autorización de una manera bastante eficiente y elegante.

Necesitas utilizar diferentes motores de bases de datos? o quizá tienes un cluster de Redis? No hay problema. Symfony te permite utilizar cualquier ORM que desees, y al mismo tiempo expone una API por si deseas desarrollar tu propio ORM.

3. Symfony es altamente extendible.

Muchas veces necesitas alterar el funcionamiento de un framework para que se acople a tu lógica de negocio. Sin embargo, alterar el funcionamiento del framework puede acarrear problemas cuando desees actualizar la versión del framework en sí.

Una de las ventajas de Symfony, es que Symfony expone una API a la cual puedes registrar eventos y servicios, que en el momento en que un "evento" suceda dentro de tu aplicación, tu código propietario puede "reaccionar" a ese evento.

Por ejemplo, si necesitas alterar el contenido de la respuesta de todos los controladores, sin necesidad de copiar/pegar el mismo código en todos los métodos, o extender la clase base de los controladores, en Symfony simplemente tienes que registrar un evento en un archivo de configuración, crear tu clase en PHP, y modificar lo que tengas que modificar. Así de sencillo.

4. Tienes el control de tu aplicación, en todo momento.

Una de mis principales frustraciones con Frameworks en general, es que a veces siento que estás programando con una caja negra.

Que siempre y cuando sigas la documentación al pie de la letra, y no te desvíes de sus estándares y prácticas bendecidas, todo debe funcionar a la perfección. Sin embargo, el segundo que te salgas un poquito de la ruta sugerida por el Framework simple y sencillamente empiezas a entrar a un terreno completamente desconocido. En Symfony simple y sencillamente eso no sucede. Primero que nada porque la documentación, es increíblemente extensa y tienen un ejemplo para una un número inmesurable de escenarios, y si te queda alguna duda, te muestran el archivo completo de configuración, con todas las opciones disponibles, y que es lo que hace cada opción.

En ningún momento sientes que perdiste el control de tu aplicación, especialmente porque la instalación estándar de Symfony viene con una barra de depuración que te muestra de manera muy granular, exactamente que es lo que está haciendo tu aplicación en TODO momento. Ésto es sumamente poderoso.

Demasiado bueno para ser verdad???

Pues si, es verdad aunque la tiene algunas desventajas. Primero que nada necesitas al menos un VPS o alguna instancia en la nube, ya sea a través de Google, Amazon, Linode o Digital Ocean para poder publicar tus aplicaciones en la web ya que necesitas tener la habilidad de poder descargar e instalar cosas en tu servidor para que symfony funcione apropiadamente. No obstante, el precio de los VPS y de los servidores en la nube son tan bajos, que los puedes conseguir hasta en $5 USD por mes.

No es la panacea universal, la gran ventaja de Symfony es tambien su peor enemigo, a veces tener tanta flexibilidad son las causas de mal diseño de aplicaciones, pero el que es mal programador va a ser mal programador con cualquier framework.

Tambien los procesos utilizan mucha memoria, en promedio cada proceso ocupa 5 MB por lo que en un servidor barato solamente podrías tener alrededor de 20 o 30 usuarios concurrentes.

Para resumir, Symfony es una gran herramienta para tus proyectos en PHP sin importar el alcance de los mismos, pero su flexibilidad es un arma de dos filos. No recomendaría Symfony para alguien que está aprendiendo PHP en lo absoluto, Symfony desde mi punto de vista es un framework para usuarios con previa experiencia en diseño de programas orientados a servicios y un conocimiento experto en el modelo MVC.

Si eres usuatio de Symfony, dejame un comentario contandome tu experiencia! Que te gusta, que no te gusta y que te gustaría aprender.

  • monsefoster

    La curva de aprendizaje es baja si y solo si, ya estas acostumbrado a otros frameworks o a MVC, pero si eres nuevo con MVC y frameworks en general, es bastante dificil de aprender, pero no imposible...

    Recientemente, he probado Rails y me ha gustado bastante, pero la desventaja (en parte) es que es en Ruby y no PHP

  • rcanales

    Hola Alan estoy de acuerdo contigo, unicamente queria hacerte una consulta talvez por si ya has pasado por ese problema, bueno te cuento he desarrollado una aplicacion Web, pero necesito controlar todos los eventos que los usuarios realizan en la base de datos INSERT, UPDATE Y DELETE, he programado algunos triggers que junto con unas tablas me realizan el trabajo, el unico problema es que unicamente realiza las peticiones un solo usuario, ya que los demas son usuarios de tablas no de base de datos, como puedo hacer para que los usuarios que se autentican y que entran al sistema tambien se han de base de datos

  • rcanales No he pasado por ese problema anteriormente, pero no entiendo muy bien que es lo que deseas hacer. 
    Quieres que cada usuario de tu aplicacion web, tambien tenga un usuario en tu base de datos y que cada usuario corra sus queries independientemente? 
    En otras palabras, 
    que si "jperez" se autentifica en tu sistema, tu pueda ver el usuario "jperez" si corras "SHOW PROCESSLIST" en lugar del usuario de tu aplicacion web, cierto?

  • monsefoster En eso tienes toda la razon, para las personas que no se han expuesto a otros frameworks y especificamente a otros MVC, si puede ser bastante frustrante.

  • rcanales

    alanchavez rcanales  
    Necesito que otros usuarios de base de datos, se puedan realizar peticiones a la base de datos por medio de la aplicacion, y no como se estable en el archivo parameters.yml ubicado en la carpeta config.

  • rcanales ahhh ya te entendi :) 

    Hmm se me ocurre una forma, pero es "fea" y no se si sea la mejor manera de hacerlo. 

    Se que puedes definir multiples entity managers en symfony y cargar cada entity manager independientemente en tu controlador. 
    El problema es que lo tienes que poner en el archivo .yml y tienes que poner un bloque "por usuario". 
    Podrias hacerlo dinamicamente (un cron job que llame un comando de symfony por ejemplo) que lea tu base de datos, y cree un bloque nuevo en tu archivo parameters.yml con las credenciales de la base de datos del usuario. 
    En la pagina de symfony oficial, hay un ejemplo de como lograr esto especificamente, pero esta en Ingles:
    http://symfony.com/doc/current/cookbook/doctrine/multiple_entity_managers.html
    Sinceramente, nunca lo he hecho.

  • hlapoint

    Hola!, me gustó mucho tu post. En los actuales momentos estoy aprendiendo PHP y me gustaría ir practicando con la realización de programas de manejo de documentos para empresas (aprobaciones de documentos, control de fechas de vencimiento de los mismos, acceso restringido a documentos según el usuario, etc.). Qué me recomiendas para esto? hay algún frameword que pienses que me pueda servir? Muchas gracias.

  • hlapoint

    alanchavez monsefoster muy bueno! entonces que podrían recomendar para alguien como yo que me estoy iniciando en MVC y nunca he trabajado con ningún framework? disculpen lo básico de la pregunta :)

  • hlapoint Si no has trabajado con ningun MVC anteriormente, Symfony o Zend Framework tienen una curva de aprendizaje bastante alta porque vas a tener que aprender demasiadas cosas en pocas cosas. Sin embargo la documentacion es soberbia. 
    De los MVC con los que he trabajado, y que tienen una curva de aprendizaje baja y buena documentacion se encuentran CodeIgniter y CakePHP, ademas estos ultimos no necesitas un servidor dedicado, ni un VPS ni nada por el estilo, trabajan bastante bien en hosts compartidos.

  • hlapoint Gracias! Para proyectos de alcance empresarial te recomiendo Symfony o Zend. Si no has utilizado MVC anteriormente, hay una curva de aprendizaje, pero el costo de aprender cualquiera de esos dos frameworks, es muy pequeño con respecto al beneficio que obtienes ya que te facilitan la vida no solamente al desarrollar sino tambien al momento de depurar errores.

  • hlapoint

    alanchavez hlapoint Muchas gracias por tu valiosa recomendación. Saludos!!!

  • Jefferson Garcia

    Symfony es muy potente, pero luego de conocer CakePHP me quedo mil veces con CakePHP debido a que Symfony tiene demasiada configuración y a mi concepto genera mucho codigo basura en el modelo. En cambio Cake desde que lo instalas ya vuela, y las relaciones entre modelos los maneja a la perfección, la validación de formularios es estupenda igual a Symfony, sin embargo Cake para hacer validaciones personalizadas es mas sencillo que Symfony. El único problema de Cake es que no hay mucha documentación pero igual desde el Book de la web de Cake me ha sido suficiente. 
    Por algo a Cake lo comparan con RubyOnRails, donde siempre he oído muy buenos comentarios de Rails de parte de desarrolladores que trabajan para empresas de desarrollo muy grandes. Asi que podria decir que Cake es un Rails pero en PHP.
    En conclusion si se tiene claro el diseño de la bd con sus respectivas relaciones, Cake se encarga del resto; ya uno mismo es el encargado de personalizar la interfaz y los diferentes procedimientos de gestionar la información en Cake.
    Yo ya probe symfony por muchos años, siendo muy buen framework, pero me quedo con Cake porque para mi es mas limpio e igual de robusto y el sistemas de usuarios y roles tambien es estupendo.

  • Jefferson Garcia Fijate que curioso que conmigo paso exactamente al reves. Yo antes era super fan de CakePHP y CodeIgniter, hasta que conoci Symfony. 
    Pero si tienes razon en tus puntos, symfony inserta mucha "basura" en el fondo, lo cual cada proceso por mas ligero que sea consume entre 4 MB o 5 MB de memoria. Lo cual puede representar un problema de concurrencia si tienes muchos usuarios y memoria RAM limitada. 
    Si empiezas a utilizar Doctrine como ORM, se pone aun peor. Doctrine consume memoria RAM a lo barbaro, especialmente cuando tienes consultas complejas con muchas uniones y joins. 
    En otra cosa que tienes razon es que Cake es una copia -casi- exacta de Rails, lo cual lo hace un excelente Framework, sobretodo en hostings compartidos, pero con Cake tengo una relacion de amor y odio con sus convenciones y nomenclaturas tan estrictas. Funciona muy bien para cierto tipo de aplicaciones, pero cuando necesitas construir una aplicacion REST o cualquier otro tipo de web service, tienes que hacer muchas modificaciones al "core" de CakePHP (o almenos lo tenias que hacer la ultima vez que utilice CakePHP).
    Con respecto a la sencillez de CakePHP, totalmente de acuerdo. el form builder de symfony tiende a dar dolores de cabeza mientras aprendes a como hacer los "overrides" de las cosas que vienen de fabrica. 
    Algo que me gusto de CakePHP 2.x es que por fin dejaron de darle soporte a PHP4. 
    Pero como dicen, para gustos los colores! Gracias por tu comentario :)

  • Jefferson Garcia

    alanchavez Si tenes totalmente razón, y el mejor framework esta en gustos y en la necesidad. Sin embargo mira que las convenciones de Cake no nos amarran, solo es una forma de hacer las cosas rápidas sin hacer tanta configuracion. Pero por ejemplo en la empresa que trabajo, desarrollamos un software ya empezado por otras personas, el cual tenia tablas en la BD que cero de convenciones con Cake... pero eso no fue una camisa de fuerza para optar por otro framework, lo unico es que cada modelo de Cake nos toco hacerles muchas configuraciones. Por ejemplo tocaba hacer cosas como
    class Coresponsalfics extends AppModel {   public $useTable = 'CoresponsalFics'; // This model uses a database table 'CoresponsalFics' 
    public $displayField = 'Name';  } Y asi mismo en los controladores tocaba hacer mas configuraciones. Entonces para mi Cake ofrece las convenciones para ahorrarte configuraciones, pero no es camisa de fuerza; y con el equipo de Arquitectura tambien se definio hacerlo con Cake porque la concurrencia para ese proyecto iva hacer alta.

  • cocotopia

    Hola Alan tendrías un ejemplo de tu trabajo hecho con Symfony ?? para poder. Gracias de antemano

  • Jesus

    Hola Alan! muy buen análisis. Estoy analizando que framewrok utilizar para un proyecto en el trabajo. Lei sobre el programa de mantenimiento y observe que la version 2.3 es la que tiene mayor tiempo de soporte, eso quiere decir que debo elegir esta versión?, la otra pregunta es que no entendi lo de VPS, que es eso? Gracias

  • @Jesus  sin duda alguna recomiendo symfony 2.3 para proyectos nuevos, aunque realmente cualquier version de symfony2 funciona muy muy bien. 

    Con respecto al VPS, es un Virtual Private Server eso quiere decir que a diferencia de los hosting compartidos, donde solamente te asignan un usuario y un directorio para hospedar tu sitio. En un VPS te crean una maquina virtual en un servidor y tienes acceso de "root" en esa maquina virtual. 
    Eso quiere decir que puedes instalar cualquier programa que necesites en tu maquina virtual, a diferencia de un hosting compartido que esta limitado a los programas que estan instalados en el servidor. 
    Para instalar symfony, zend o cualquier otro framework "pesado" es casi casi necesario tener un VPS. Uno muy barato y muy bueno es ramnode.com te lo recomiendo bastante.

  • jesmarquez

    alanchavez Ok, no tengo problemas pues lo alojaría en unos servidores de la empresa. Gracias!

  • Jefferson Jair Arcos Erazo

    Personalmente creo que CakePHP ha sido y es el mejor de todos los frameworks mvc para php =)

  • Paul

    hola Alan, yo recién estoy empezando a aprender todo esto de programación web, php, etc. y un amigo me dijo que symfony tiene una curva de aprendizaje rapida y me va a servir para desarrollar proyectos, que me recomiendas tu? porque leo que tu dices que para empezar no recomiendas que se use este framework

    • Hola Paul, gracias por comentar!
      La curva de aprendizaje es algo subjetivo, quizá tu amigo tiene mucha experiencia o es muy inteligente y lo aprendió relativamente rápido.

      Sin embargo, bastantes personas me han mencionado con Symfony es relativamente lento de aprender. Y con "relativamente lento" es que alguien completamente nuevo con frameworks de PHP es probable que invierta alrededor de unas 2 o 3 horas antes de poder ver un "Hello World" en pantalla :)

      Pero si vienes de un Framework como Silex o Laravel, realmente puedes aprender Symfony en cuestión de horas. Primordialmente porque Silex y Laravel toman prestados muchos componentes de Symfony.

      Definitivamente vale la pena aprenderlo, es un framework muy robusto y poderoso, pero si nunca has manejado Eventos, Routing, Sesiones, Autorización, Autenticación, Apache, PSR, Composer, etc... Symfony si puede llegar a ser agobiante :)

  • Muy buen post estimado Alan! Lo cierto es que en mi caso yo he pasado de rails a cakephp, y hoy estoy trabajando en un framework llamado KumbiaPHP. La comunidad es pequeña dado su carácter latino/español, pero tiene una calidad de código que ya se la querrían varios frameworks. Por estos días los muchachos del core están trabajando en los detalles del lanzamiento, pero si sirve de referencia nosotros en la empresa hemos hecho aplicaciones bastante robustas usando la versión beta. La documentación del core está en español, y hay mucha gente amable y deseosa de ayudar. Para más información puedes pasarte por http://www.kumbiaphp.com te aseguro que puede llegar a tambalear cualquier framework por su velocidad y calidad.

  • Pedro Reina

    Pues yo también estoy lidiando con symfony y vaya que si tiene cosas buenas, pero malas también.
    Estoy usando la version 3.1 y me he propuesto un proyecto practico. He estado picando 2 semanas sin parar para una web que computa horas de un equipo de trabajo, siguiendo vídeos manuales y tutoriales y todo han sido problemas, cosas not found, métodos que no sirven de versiones anteriores, el acl no funcionaba bien, integrar un form login a sido todo un reto y con apaños raros...
    Alan comparto tu misma opinión sobre los frameworks que a veces tienes que hackear, como codeigniter.
    Estoy pensando en bajar mi nivel y aprender phpcake pero me preocupa no saber donde me estoy metiendo.
    Y voy a preguntar lo contrario de lo común ... alguien me DESaconseja phpcake por algo en concreto?
    Ya lei que symfony es fuerte, pero lo que me mosquea es que algunas cosas no funcionen como están documentadas.
    Los formularios un rollo seguir el patrón, es muy estricto y si en algún form decides no incluir algún widget-field, te lo renderiza por narices al pie del formulario.

    • Hola Pedro,

      Los formularios de Symfony es una de las pocas cosas que prefiero no utilizar, precisamente por las cosas que menciones en tu POST. A decir verdad, en los últimos proyectos que he trabajado con Symfony no han sido sobre APIs REST.

      Si quieres un framework menos complicado, podrías explorar Silex o Lumen. Lumen es esencialmente Laravel sin todas las convenciones de Laravel que en lo personal me parecen invasivas. Silex se parece un poco más a Symfony (es básicamente micro Symfony), pero sin todas las complicaciones.

      Con respecto a Cake PHP, el principal problema que Cake tenía hasta hace poco es que se tardó mucho en actualizarse. Cake 2 estaba muy muy muy atrasado con respecto a las prácticas modernas de PHP, y los programadores empezaron a preferir frameworks con mejores prácticas como Laravel, Silex, Lumen y Symfony. Cuando se liberó Cake 3, se notaba mucho la inmadurez del producto en la manera en la que funcionaba, y no es que fuera malo en sí, sino que hay alternativas que son mucho mejores.

      Si quieres aprender un framework menos complejo como Symfony, te recomiendo que empieces con Laravel, y si Laravel aún te parece mucho, entonces te aconsejo que empieces con un Micro framework (Silex/Lumen/Slim)

      • Pedro Reina

        Que pena, pensé que me hablarías maravillas sobre php-cake.
        He visto que el mercado actual valora bien ese framework y se buscan programadores de ese framework.
        Me fastidia bastante dedicar meses de mi escaso tiempo para aprender frameworks y luego me digan que ha sido para nada.
        He estado en contacto con una empresa que busca gente de php, y me comentaban que apuntaban para symfony, parece ser que la gente no está viendo que symfony es bueno para REST y quizás no tanto para aplicaciones pequeñas.
        He visto el mencionado Kumbiaphp y me parece muy interesante, tiene buena pinta, toda la documentación en Español, y se ve mucha ilusión en ese proyecto, pero claro, al final siempre estamos con lo mismo, demasiada diversidad para hacer lo mismo, y me veo obligado apostar por algo, porque no voy a aprender 3 frameworks diferentes como el que echa la quiniela. Para mi puede ser igual de bueno uno u otro para hacer mis apps, pero debo tener en cuenta las posibilidades a la hora de desarrollar para alguien externo o sobre las posibilidades laborales.
        Sobre symfony también me parece un frente enorme el tema de las configuraciones y el ORM tan complicado para hacer una miserable relación entre 2 tablas.
        En resumen symfony es horroroso jajajajajajajaa

        • Sinceramente no he utilizado en lo absoluto Cake 3, que resulta ser la última versión de ese framework, pero he visto la documentación y los ejemplos, y al parecer está apostando a un PHP más moderno.

          Con respecto a dedicar meses de tu tiempo para aprender un framework, y al final no lo utilizas. Esa es la vida del programador, toma por ejemplo el mundo de JavaScript. Hace 3 años todo era sobre Grunt, hace 2 años todo era Gulp. Hace 3 años todo el mundo tenía que aprender Angular, y ahora la comunidad se está moviendo hacia React.

          Symfony si es un "overkill" para aplicaciones pequeñas, te vas a tardar más escribiendo las anotaciones/archivos yaml para Doctrine, que escribiendo una consulta para hacer un "SELECT * Usuarios"

          Los ORM son ideales cuando tienes un montón de tablas, y existen relaciones complicadas entre las mismas. Cuando tienes solamente unas cuantas tablas, y la consulta más complicada que vas a escribir va ser una con 3 JOINs, entonces un ORM tiende a ser "overkill".

          Lo que te aconsejo es que no te "cases" con un Framework. Si la gente me dice "Oye sabes utilizar Cake 3?" generalmente voy a decir que si no porque sea deshonesto, sino porque una vez que aprendes un lenguaje bien, tienes fundamentos sólidos de programación orientada a objetos, conoces varios patrones, y has trabajando con un número diversos de Frameworks, aprender un Framework nuevo es algo trivial. Hace unos meses tuve que aprender un Framework nuevo en un lenguaje con el que tenía poca experiencia, y hoy en día, me desenvuelvo en ese framework como si lo hubiera estado usando por años.

          ¿Por qué?

          Porque ya sé que es lo que necesito hacer, cómo lo tengo que hacer, bajo que condiciones tiene que funcionar, y simplemente tengo que aprender la manera ideal de lograrlo en las herramientas que se me han dado. Así que no te desanimes si aprendes una cosa, y otra persona te dice que aprendas otra. Al final vas a estar aprendiendo cosas que eventualmente se van a des continuar, y si quieres mantenerte relevante vas a tener que estar reactualizandote cada 6 meses.

          • Pedro Reina

            Overkill!!!!!!!
            Tardar más tiempo en diseñar con anotaciones y yaml!!!!!

          • Pedro Reina

            Parece muy sensato todo lo que dices, se nota que sabes de que hablas, y pensado así en frío tienes razón, la tecnología se está convirtiendo en algo que quien puede pillar las cosas al vuelo y adaptarse se queda.. y si no....
            Yo es que soy muy de casarme, cuando estaba en Visual Basic me hizo ilusión meterme en php porque el progreso era evidente y el lenguaje C me venía de antes. Pero me va más especializarme que ir picoteando.
            Domino bastante bien php, incluso estuve haciéndome mi propio framework pensando que no iba a ser capaz de meterme en ninguno, y ahora me doy cuenta que estaba reinventando la rueda, haciendo cosas muy similares a las que hay en estos...
            Pero esto de tantos frameworks es un drama, veo que es más complicado aprenderse todo esos entornos que aprender el propio lenguaje, que paradójico.
            Voy a tirar por phpcake y como tu dices, sin casarme. Phpcake me parece bien para un buen comienzo, y cuando lo tenga más o menos manejado sin dominarlo del todo iré picoteando, laravel pinta bien pero mucha gente dice que está sobre valorado, pero como es algo que se pide también laboralmente, o como se pide symfony y en ese caso pueden dar por válido a laravel, pues...
            No me enrollo más, me has ayudado mucho.
            Muchas gracias!!!!!

    • Ariel del Valle Carnicero

      Cuando tengas un tiempo lee mi comentario de arriba, yo personalmente te recomiendo muchísimo Symfony por encima de Cake (lo uso en el trabajo y a mi gusto se queda muy corto)

      • Pedro Reina

        Hola Ariel.
        Yo entré hace unos 2 años en codeigniter, como era una necesidad del cliente y todo fue muy rápido no me enteré de mucho.
        Entrando en Symfony era como si entrara la primera vez en un framework, siempre he intentado escapar de estas cosas, pero al final te ves obligado si quieres trabajar en grupo o tener oportunidades colaborativas o laborales.
        De symfony lo peor es lo fuerte que te somete sus convenciones, han convertido lo moderno de php (namespaces uses y demás) en un intento de convenciones que en realidad son imposiciones.
        No me digas tu que para un form tengas que depender de 8 "uses", generalmente uno o dos por cada control y también para cosas tan livianas como evitar entradas duplicadas.

        ¿Sabes la conclusión final que he sacado? que estamos obsesionados en estar siempre al lado del más grande, pero a veces el gigante nos queda grande y no nos da lo que necesitamos.
        Es como cuando me metí hace entre 15 a 20 años con un linux poco currado, inmaduro y pocas aplicaciones, no buscaba lo mejor, buscaba un terreno apacible donde hacer mis 4 cosas y no hubiesen win-problemas.
        Ahora esa antigua alternativa es ahora mi casa y el jardín de más personas cada día.
        En un foro en inglés alguien me dijo al respecto "te doy un consejo, no te cases con nadie, haz progresivamente lo que te parezca mejor y hazlo disfrutando".
        Y creo que es lo que haré.
        Ahora estoy con KumbiaPhp, que pensé que sería algo informal con mal soporte o prácticas raras, y todo lo contrario, facilita todo lo que te imaginas y más.
        La curva de aprendizaje es casi una recta, disfruto mucho aprendiendo, incluso las peores cosas puedes mirar en el nucleo y todo se entiende de un vistazo.
        Tiene muchas cosas de Jquery integradas que las puedes llamar desde sentencias php.
        Integrar un input-text con el calendario, no necesitas hacer nada, ni javascript ni css, todo eso es 'piloto automático' sólo definir en el formulario un Form::date y el calendario sale sólo. (Esto puede que no sea del todo bueno para los nuevos, pero los que estamos aquí somos lagartos verdes y sabemos que es un js y un css y sabemos que controles están tirando de ellos)
        Los problemas con los objetos del formulario, que en symfony fueron muchos, con Kumbia un camino de rosas.

        Por otra parte, y debatiendo... ¿Que puede haber que un framework te quede pequeño, cuando todo lo que no hace un framework lo puedes codificar tu?
        Yo he hecho cosas grandes a pelo, programas de gestión y facturación, un intento de piwik a lo cutre, estuve fabricando mi propio mini-framework, y sí, con un framework me hubiese facilitado la vida muchas veces, pero todo lo que no puedas hacer con un framework siempre podrás hacerlo con implementaciones u objetos propios.
        Decir que un framework queda corto, cuando al grande le tienes que dedicar 3 o 4 días en lograr colocar un formulario en condiciones, en dedicar 3 horas en porqué no me sale esto porque al final necesitabas un "use" o lo que estás leyendo es de tu misma versión pero a ti no te funciona.
        No se.. todo es muy relativo.

        Creo que mi entrada y progreso va a ser disfrutando con lo pequeño y creciendo poco a poco. CakePHP no me ha parecido mal ejemplar para una segunda caza.
        Laravel lo que he ojeado es un symfony simplificado y pinta bien. Tampoco hace falta que sea explicitamente el mejor jejejejeje

        Creo que para symfony, ya tendré tiempo, o quizás lo aprenda currando si alguien lo quiere pagar, es tontería meterme en cosas muy grandes para que luego no me sirvan para cosas personales y no me abran puertas profesionales.
        No digo que no, o que no lo vaya a hacer, pero de momento lo dejaré en una sweet, a ver si llego.

        Quien no haya visto KumbiaPhp, que lo ojee.
        Recomendable para gente iniciada, o gente que domine pero eche en falta algo más amigable y que ayude a codificar rápido.

        http://wiki.kumbiaphp.com/KumbiaPHP_Framework_Versi%C3%B3n_1.0_Beta2

        https://docs.google.com/document/d/1kth1GhrmMEBK2cAMyiy_4Dw1qlJFNdXVuXajJ6nMTQg/edit?hl=es&pli=1#heading=h.sr6s5m-g96n1n

        Si veis gente entusiasmada con KumbiaPhp no es que porque les parezca correcto como otros frameworks, es que te permite hacer grandes cosas muy muy rápido.
        Pocas convenciones, los modelos mapean las tablas y no necesitas definir los campos, se definen solos con todas sus propiedades y sus índices. Las relaciones muy muy fáciles de hacer.

        Esa es mi conclusión, es bueno aprender todo y poco a poco, y si alguien como yo empieza con mil dudas y sin conocer nada, lo mejor es como el que sale a hacer turismo, ir picoteando y disfrutando... ningún turista busca el mejor lugar para quedarse allí.

        P.D:
        Ariel, Doctrine es horroroso!!!!!!!! y si encima devora recursos... vamos que nos vamos jajajajaja

        • Ariel del Valle Carnicero

          KumbiaPhp tendré que revisarlo, realmente ni lo había visto nunca, el comentario de Doctrine te lo acepto, jeje, de hecho fue de las cosas que critiqué pero eso no es Symfony.
          Te menciono lo de Cake porque aquí en el trabajo al final tuvimos que cambiarlo, estamos migrando los proyectos a Codeigniter en este caso (ya estaba seleccionado antes de yo llegar). pero lo que está en Cake no está muy bueno (aunque esto va de la mano con el mal desarrollo) no solo es el framework.
          El Laravel es casi symfony sin Doctrine (lo sustituyeron por Eloquent), yo actualmente en algunos desarrollos lo que hago es mi propio código como mencionas, y lo que si estoy es reutilizando los componentes de Symfony que encuentro buenos o me resuelven una tarea específica, y así domino la mayoría del código que tengo y es mucho más rápido.
          Te pongo por ejemplo el http-foundation que para mi es de lo mejor de Symfony en componentes por las clases que trae, y otro ejemplo es que tuve que hacer scraping de unas páginas html y descargué los componentes dom-crawler y css-selector y con eso ya resolví.
          Y de esa forma al final es más flexible, porque si no te gusta un ORM por ejemplo descargas el que quieras o implementas uno y ya.
          Lo que pasa que para esto lo más recomendable es ya tener unos años viendo este tipo de tecnologías, y usando los patrones de diseño, en este caso MVC.
          Esta vía a mi me sirve mucho por ejemplo para usar con el extjs que menciono, pues con symfony pierdo de todas formas todo el uso de twig y los form(muy malo, jeje) y parte de la seguridad, entonces me es mejor por componentes separados, y le pongo cualquier ORM, en el caso que trabajé usé ActiveRecord que es el de Codeigniter que me gustó y es bastante rápido.
          Eloquent quiero probarlo pero no he tenido tiempo.
          Lo que si realmente como Framework el que más me gusta en conjunto es el Symfony, y está claro que no te sirve perder el tiempo si no tienes trabajo pero por ejemplo aquí en Chile, y en España hay bastantes trabajos que lo piden también.

          Saludos.

          • Pedro Reina

            jijijiji, perdona que te contradiga, pero cuando dices "pero eso no es Symfony" hablando de Doctrine, bueno.. pues depende, en un mundo donde atentan contra ti diciendo "hacienda somos todos", y donde las empresas que triunfan no sale tu nombre pero si cuando fracasan y dicen "si se hunde el barco, nos ahogamos todos", pues si Symfony cuenta con Doctrine como parte de sus bondades, hay que cualificar el pack entero, además de que muchos nos sabemos y probablemente no seamos capaces de cambiar un Orm de un framework para cambiar otro.
            El Orm de codeigniter es Activerecord no?
            Es que creo que KumbiaPhp tiene el mismo Orm que codeigniter, he visto gente hablando bastante mal de activerecord, pero yo no le veo nada malo.
            En los modelos de Kumbia las clases dicen "class ActiveRecord extends KumbiaActiveRecord"
            Probablemente Laravel esté bien valorado por eso, por ser hijo de symfony sin sus verrugas, sin tanta configuración de anotaciones y yaml, y sin doctrine.
            Pues mira que es gracioso, sobre symfony, a muchos no les gusta su Doctrine, a otros no les gusta el sistema de formularios, a muchos no nos gusta sus convenciones tan masivas y literales, y otros muchos dicen que es el mejor framework.
            Debe de ser muy potente y versatil, porque valorar un herramienta no debería ser sólo por lo que se fabrique con él, también ha de contar su accesibilidad y facilidad, de ser por esa regla los lenguajes visuales deberían de estar muy muy mal valorados por ser lenguajes interpretados y tan lejanos del lenguaje máquina.
            Pues sí algún día te aburres prueba Kumbia, igual te da una sopresa, si es de facil como codeigniter y lo ves como un progreso del mismo y fácil de migrar, en tu empresa se pondrán contentos con tus habilidades.

          • Ariel del Valle Carnicero

            Si, es activerecord, a mi realmente me agrada bastante, y tiene muy buena velocidad, hasta ahora me gusta más que Doctrine, no me preocupa que me contradigas, si todas las opiniones fueran en el mismo sentido nadie mejoraría, de hecho yo soy de los que le gusta Linux también, uso windows porque tengo un juego que solo funciona ahi, jeje.
            Cuando te digo que eso no es Symfony es porque los componentes de Symfony como tal están muy buenos (quitando el formulario y alguno que se me quede por ahí) lo que está malo es la integración que le han dado, en cuando a lo que mencionas de limitarte a la forma de trabajar, realmente no entiendo bien, pero en este caso soy de la opinión que tener restricciones en cuanto a como escribir el código es bueno, porque tienes que pensar que normalmente trabajas en equipo, y además llegas a un trabajo nuevo y todo el código está escrito de mil formas distintas dentro de un mismo fichero php, y al final te pierdes, pero bueno, para gustos se hicieron los colores.
            En cuanto al Kumbia lo que vi en lo que me enviaste es que es un beta todavía, creo, no estoy seguro, de ser así todavía no lo probaré, esperaré a que salga una versión estable.
            Lo de las configuraciones sigo sin saber a que te refieres con muchas configuraciones porque realmente yo hago muy pocas, lo que si he visto con muchas configuraciones es a la hora de integrar Bundles de terceros, coméntame un poco más de este tema.

          • Pedro Reina

            Active Record, pues ahí tienes una ventaja con Kumbia.
            Lo de las betas, pues no se, mucha gente lo comenta, porque está en Beta algo que es 100% funcional.
            Del Beta 1 al Beta 2 cambiaron algunas cosas, pero pocas.
            Lo más ha sido algunos Helpers y objetos que eran instanciados y ahora se usan sus métodos como estáticos, nada que no pueda arreglar un "refactory" de cualquier ide como netbeans.
            Lo de trabajar en equipo y las reestriciones, tienes razón, pero todo esto también puede suponer un gran coste en formación y tropiezos de los menos expertos.
            Lo de las configuraciones de Symfony, pues verás.
            Yo empecé siguiendo a Edson Mollericolla que da un curso muy bueno por youtube, y hizo un trabajo sublime, muy ameno y muy entendible.
            La pena es que ahora mismo nada de lo que él explica ni su proyecto descargarble en github no sirven para nada, puedes pillar ideas, pero los ejemplos no funcionan ni de lejos.
            Algunas cosas que traté de arreglar y adaptar fueron un suplicio y un camino amargo, y algunas cosas la gente decía solucionarse aplicando directivas y cosas raritas sobre el security.yml y otros ficheros, como si fuesen extensiones o habilitaciones.
            Lo del ¿Acl? para los logins, pues también tocas ficheros de ese tipo, aunque no sea tan complicado.
            Algunas muchas cosas que no recuerdo iban por el mismo camino, aplicables sólo si modificabas esos ficheros.
            No se, quizás sea para limitar el uso de recursos, no se, pero complica mucho la cosa. Supongo que ya me pillas la idea.

          • Ariel del Valle Carnicero

            Hola, seguire Kunbia a ver como le va, con lo del acl que mencionas yo no toco ningún fichero de configuración extra, a no ser que me ponga a usar FosUserBundle y esas cosas pero si lo haces con el Symfony puro solo es el security.yml pero es bastante sencillo y es una configuración que casi es copiar y pegar, por eso te preguntaba. Y lo de acl (yo lo que uso es la propiedad access_control dentro del mismo fichero security) pero es también bastante sencillo, pero te digo, la parte de seguridad la implemento yo solo con las cosas basicas del framework, no con bundles externos.(que no se si sea el caso), pero cuando traté de usar en su momento el FosUserBundle, eso si llevaba bastantes configuraciones.

          • Que bonito es ver profesionales argumentando sus puntos a favor en contra sin llegar a los insultos :)

            He estado leyendo la conversación, y ambos brindan buenos argumentos a favor y en contra de sus preferencias.

            En lo personal me gusta Symfony, y Doctrine no me parece tan malo cuando todas las relaciones están bien mapeadas. Algo que cabe resaltar es que Doctrine NO utiliza ActiveRecord sino Data Mapper.

            Una de las ventajas de utilizar Data Mapper es que las entidades son simples clases en PHP que no tienen una clase padre, ni te orillas a utilizar convenciones y opiniones de los desarrolladores de Doctrine, por lo tanto las ventajas más grandes de Doctrine sobre otros ORMs es que las entidades de Doctrine:

            1. No tienes el problema del "gorila y la banana" (leer: http://www.johndcook.com/blog/2011/07/19/you-wanted-banana/ )
            2. Se pueden escribir pruebas unitarias facilmente.

            Además Doctrine implementa los patrones lazy y eager loading, en lo personal me gusta lazy loading porque te permite manipular la entidad como si estuviera totalmente cargada en memoria, pero no jala la información de la base de datos hasta que dicha información sea absolutamente necesaria (en demanda)

            Y como mencionaron anteriormente, una de las cosas más fuertes de Symfony es el componente Http Foundation en mi opinión es una de las mejores implementaciones de Http en un Framework que he visto, no solamente en PHP sino a través de multiples lenguajes. Es tan buena que el mismo autor de Laravel dijo en alguna ocasión "No hay necesidad de reescribir algo que ya funciona perfectamente bien"

            Actualmente estoy desarrollando una API RESTful en Symfony 3.1 y el framework ha mejorado bastante, cuando recién empecé a utilizar Symfony las peticiones generaban una huella en memoria de alrededor 20MB por petición, y ahora en esta API que estoy haciendo cada petición tiene una huella de alrededor de 2MB. Bajo algunos estándares 2MB de huella en memoria sigue siendo batante, pero al menos bajo los míos 2MB por petición para una API RESTful de complejidad media me parece bastante aceptable.

            Otra de las cosas que me encanta de Symfony fue que tan fácil se me hizo implementar autenticación y autorización con JWT, escribir un Listener para CORS, y el middleware para validar los tokens para todas las peticiones.

            Otro Framework que tengo en mis planes utilizar es Phalcon que todo el framework en si está escrito en un lenguaje llamado Zaphyr que es eventualmente transpilado a C e instalado como una extensión. He visto que Phalcon tiene la capacidad de servir miles de peticiones por segundo dejando una huella en memoria mínima.

          • Ariel del Valle Carnicero

            Tienes razón a mi ver en casi todo, jeje, sobre todo en lo de no insultarse, no hay necesidad, hablando la gente se entiende. Lo único es que cada uno tiene sus preferencias y es evidente que no todos vamos a estar de acuerdo en todo, si fuer así existiera un solo framework (en este tema), yo no creo que Doctrine sea "MALO", sino que en temas sobre todo de velocidad me deja mucho que desear cuando pruebo por ejemplo ActiveRecord con Codeigniter, esto te hablo de un ejemplo hecho en Extjs para todo lo que es la vista y con Symfony (Doctrine) sin usar los form y Codeigniter (ActiveRecord), y con Codeigniter me gusta menos el diseño pero es 2 o 3 veces más rápido y cuidado no más.
            De Symfony lo que mencionas de autenticación y autorización yo en general diría que toda la parte de seguridad la veo muy superior.
            En estos momentos me estoy haciendo un digamos(microframework) con los componentes de symfony como base, para integrarle otro ORM (pienso por ahora en ActiveRecord o Eloquent), este último porque quiero probarlo a ver como me va.
            Es que los componentes de symfony para mi están geniales, ya probé en un proyecto el dom-crawler y css-selector y van muy bien.
            Me parece que a la hora de integrar como han querido hacer el framework full-stack se han complicado un poco y seo lo hace un poco lento, me refiero a por ejemplo cuando haces una petición, te das cuenta que se llaman e instancian n clases y servicios y uno no usa ni la mitad, son llamadas internas del mismo framework la mayoría y eso resta bastante rendimiento.
            Y a Doctrine una de las cosas que precisamente lo hacen más lento (aunque me guste) es el mapeo a clases de php, y de todas formas te soy sincero, cuando hago una consulta para sacar datos, normalmente le hago un getArrayResult para que me lo devuelva como arreglo solo con los datos que necesito porque el objeto DoctrineCollection es bastante grande, y casi te obliga a paginar a nivel de servidor (buena práctica) pero muchas veces no puedo hacerlo por obligación.
            Dame algunas opiniones al respecto, lo bueno del debate para mi es ver opiniones diferentes también, para analizarlas no para rebatirlas (al menos no todas) y creo que hasta ahora cuando ha salido una tecnología nueva la he probado y si me gusta más me cambio y trato de adaptarme a ella, y no estancarme en lo mismo siempre.

  • Ariel del Valle Carnicero

    Hola:

    Me gustó bastante el artículo, y quisiera comentar algunas cosas para el que le interese. Comentario: Me encanta Symfony pero hay que reconocer también lo malo, jeje.

    Primero lo malo:
    - Realmente ya he visto otros framework y he trabajado con ellos y son mucho más rápidos que Symfony. Esto básicamente es por una parte a Doctrine, no al Symfony en si, esta parte si deseas integras otro ORM y lo solucionarías. Lo otro es que mencionas en el artículo un tiempo de respuesta, que en mi experiencia es el tiempo que te pone el profiler de symfony cuando lo ves, pero en la realidad por ejemplo la carga de una página web demora mucho más, sobre todo el render de las plantillas y la carga de componentes internos (Esto se puede mejorar también si desactivas componentes que no uses y cambiando el gestor de plantillas a php, aunque sigo prefiriendo twig, lo que pasa es que symfony te transforma las plantillas de twig a php pero le agrega código innecesario para uno pero necesario para el framework).
    - El tema de los formularios aunque está bueno es un poco complejo cuando tienes necesidad de interfaces con relaciones entre los campos y esas cosas, ahí se complica más, yo prefiero usar html (twig) y javascript y capturar los parámetros a mano en el controlador, y principalmente si la aplicación es de gestión básica uso extjs para la interfaz.

    Ahora lo bueno:
    Realmente leí los comentarios y no estoy de acuerdo con algunos, estoy de acuerdo con que el mejor framework es el que más te guste o te sirva según el proyecto que desarrolles, Symfony no es para proyectos pequeños.
    La curva de aprendizaje no es lenta, al contrario, en unos minutos estás tirando código y de buena calidad.
    Esa cantidad de configuraciones que mencionan, no sé de que tema estarán hablando, pero hasta ahora solo configuro el fichero de seguridad, el de base de datos, y una o dos cosas más, lo servicios por ejemplo dependiendo de si los usan, pero además son configuraciones super fáciles. Y esto es en todos los frameworks (lamento si alguno por ahí no las tiene, pero hasta ahora los que yo he visto, hay que configurarlos igual) (Codeigniter, Silex, Yii, CakePHP, Laravel)
    Una cosa muy relacionada con solo configurar el archivo de seguridad, crear la clase usuario y un método de login que es copiar y pegar directo de la documentación, ya tienen implementada una seguridad de buen nivel en el proyecto.
    Les comento que uso annotation porque aunque parezca más complicado al final es mucho más sencillo y flexible de lo que parece. Al menos a mi que era fan del yml me gusta ahora mucho más.
    La configuración de las entidades no entiendo que tanto tiempo les lleve pero yo sencillamente copio el código que tengo, eso si, las relaciones entre una clase y otra es un poco rara, pero es cuestión de hacer una sola bien y las demás son iguales.
    Con el tema de la documentación hasta ahora a mi al menos todo me ha funcionado perfecto, solo me ha dado conflictos cuando estoy leyendo una documentación de una versión que no es la que estoy usando.
    Otro tema es que tengo bastante cuidado a la hora de usar un bundle externo aunque sea famoso, muy utilizado o lo que sea, hasta ahora mis experiencias en este tema no han sido muy buenas debido a que al final necesito modificar algo en esos bundle y son un laberinto para modificarlos.

    Se me debe quedar algo por ahí pero básicamente es mi experiencia con Symfony, hasta ahora especial, no lo cambio por ninguno.

A %d blogueros les gusta esto: