Symfony 2 : avantages et inconvénients

Après bon nombre de commentaires, voire d’insultes (si si), je résume l’article qui suit :


Vous allez toujours entendre le même discours pour ceux qui commencent avec Symfony et qui n’ont jamais vraiment développé d’autres choses, qui est quelque part logique : Symfony c’est génial, c’est super, c’est la réponse à la vie, l’univers, et au reste, il aurait dû s’appeler « Php – 42 » ou quelque chose comme ça (et si vous ne comprenez pas l’allusion c’est qu’on n’a ni le même background, ni le même humour). C’est, de plus, très souvent le genre de personnes qui n’admettent pas qu’ils n’ont pas d’expérience et cela finit à l’insulte ou au pugilat.

S’ils avaient vraiment pratiqué d’autres choses, il verraient qu’il y a plein d’autres trucs ailleurs, et ils verraient qu’à d’autres endroits il y a des choses mieux.

Ceux qui n’ont pas d’expérience mais l’esprit ouvert me demandent ce qu’il y a comme autres choses à tester, et je leur réponds avec plaisir ! Ceux qui n’ont pas d’expérience et ont besoin de justifier leur existence diront « c’est un gros con il est dépassé il n’y comprend rien ». Je ne donne des cours que pour les premiers. Les autres je les laisse faire alt-tab en permanence entre Facebook et Symfony (et si vous saviez tout ce que je pense quand je parle ainsi…).


Après avoir développé deux applications relativement basiques, voici les inconvénients que j’ai relevé de Symfony :

  • Twig : c’est la seule chose qui semble vraiment pratique, utile et optimisée dans Symfony. A tel point que Zend l’utilisera comme moteur de templates, et Drupal 8 aussi. Un bon point pour Symfony, et le seul. Voici la suite.
  • Symfony prône les bonnes pratiques – ce qui est louable – pourtant j’ai dû faire trois fois du copier coller pour que ça fonctionne… Exemple le plus frappant : la bonne pratique (louable) est de séparer totalement la vue du modèle, et du contrôleur. Mieux : ils ont fait un endroit où on écrit toutes les requêtes complexes, afin de les séparer du modèle : ce sont les Repositories. Problème concret : quand on a un type fichier dans un formulaire qui est envoyé, le type « file » est posté. Si on veut écrire le fichier envoyé, ça passe par un contrôleur, et c’est lui qui est censé l’écrire en base de données ? Non ! Donc c’est côté de la base de données, côté modèle donc. Mais… les entités ne peuvent pas accéder à leur propre repository ! Si vous vous retrouvez dans ce cadre (hypra courant) alors vous allez devoir bidouiller, et créer une fonction statique qui renvoie le manager d’entités et demander à ce dernier de récupérer le repository de la classe en cours. Véridique. Bidouillage, bidouillage, bidouillage. Pourtant, j’insiste : Symfony prône les bonnes pratiques et essaie de faire au mieux, mais il échoue assez… attendez je cherche le qualificatif exact… j’ai trouvé : il échoue lamentablement.
  • Je pensais gagner du temps avec le bundle FOSUser. Faux ! En théorie il est censé simplifier la vie à mort et faire gagner énormément de temps. En pratique, c’est comme Symfony, il va vous falloir entrer dans son coeur, comprendre comment il a été écrit afin de pouvoir vous en servir. Exemple concret là aussi : il n’est fait que pour un seul type d’utilisateurs. Si on en veut plusieurs, il va vous falloir installer un bundle supplémentaire : le PUGXMultiUserBundle. Quelques heures plus tard après l’installation et la configuration, on m’a demandé de créer un rôle modérateur, qui doit pouvoir valider les fiches d’inscription, c’est à dire pouvoir afficher n’importe quelle fiche. Je ne peux même pas vous expliquer comment faire, car j’ai demandé aux experts Symfony – ce sont des personnes qui m’ont sous-traité le second travail que j’ai fait sur Symfony, de le faire eux même parce que je n’en pouvais plus de perdre autant de temps inutilement. J’ai beau chercher, mais un bon développeur Php va perdre beaucoup plus de temps à rechercher tout ça, installer, comprendre le fonctionnement, copier coller puis modifier le code, plutôt que de le faire direct à la main, avec des variables dans $_SERVER pour suivre quelques infos.
  • Symfony et le redimensionnement d’images. Je voulais juste, une fois qu’une image est arrivée en base de données, créer une vignette de cette dernière, afin de pouvoir l’afficher plus rapidement. J’ai donc cherché et voici le résultat – vous noterez bien qu’il est affligeant si on veut simplement redimensionner une image : en théorie  :
    • il faudrait mettre en place un service,
    • à partir de ce service, aller chercher des informations,
    • mettre en place toute une configuration, avec un système de hook (les « écouteurs »)

    … bref, refaire des milliers de choses d’une inutilité absolument affligeante, tout ça pour faire un simple resize. Après avoir passé plusieurs heures à installer le LiipImagineBundle : et m’être aperçu que pour faire un resize, il fallait déclarer vouloir utiliser un service dans ‘app/config/config.yml’, je vois qu’il y a un exemple qui est censé fonctionner sur stackoverflow ici. Et puis là le code qui fonctionne utilise getRequest(). Et le container. Moi j’en avais besoin dans l’entité, car c’est ici qu’on écrit les informations en base de données. Pour pouvoir accéder à un container dans une entité, il faut faire un méga hack, ou pire (lire les deux réponses ici). La seule réponse viable c’et de.. créer un service ! Non mais allô quoi ! Juste pour un crop ! Vraiment on est en plein délire. Hop, top chrono : google =» php imageresize, copier coller, et en moins de 5 minutes, tout fonctionnait. Symfony clame haut et fort qu’il vous fait gagner des heures de boulot ? C’est une blague, une grosse blague ! Posez les pieds sur terre, voici la réalité concrète du terrain : Symfony essaie de pousser encore et encore l’abstraction à son maximum mais on arrive à des non-sens comme celui-là : une entité qui appelle deux services différents, surchargés à mort, des centaines de lignes de code totalement inutiles, juste pour faire un resize. C’est tellement grossier comme problème qu’on en arriverait presque à croire que c’est faux… mais c’est vrai, et les liens que j’ai mis sont bien là pour le prouver.

  • Doctrine est quelque chose… que je ne comprends pas. Il a été crée pour « optimiser » les requêtes. Déjà, rien que d’écrire ça, c’est inévitablement un non sens : on n’optimise pas les requêtes via du Php… À moins que je ne me trompe, on n’a jamais besoin d’optimiser les requêtes à ce niveau ! L’optimisation et la mise en cache doit se faire au niveau du moteur de bases de données. Pourtant, là, on doit écrire du SQL, mais pas vraiment. Olivier arrête de dire n’importe quoi me direz vous. Pourtant ça n’est pas une blague, lisez tout ça ici. Tout y est expliqué : ils ont « surchargé » l’écriture de requêtes, afin de… pouvoir optimiser les requête et mieux faire du cache. Si si. Et ils ont même inventé un concept super novateur, que personne ne connaissait avant (grincement de dents cynique), j’ai nommé : l’hydratation (ou en anglais : « hydration »). Non non, j’insiste, arrêtez de rigoler, c’est pas une blague, ils prennent ça très au sérieux là bas, regardez sur la documentation officielle et cherchez « hydration ». Par contre pour bosser il faut absolument savoir ce que ce mot d’une débilité profonde – au sens informatique – signifie : j’ai mené un entretien d’embauche avec une personne (qui se disait expert), et comme je n’ai pas parlé d’hydratation des données, ça ne lui a pas plu. Bon quand je dis « expert », il faut dire qu’il s’était fait dégager à grands coups de pieds au derrière par sa précédente boîte… j’arrête là je vais être méchant 😉
  • Avec Doctrine, on se prend tout le temps la tête sur les requêtes, ce qui fait qu’au final, comme jamais rien ne fonctionne comme on voudrait avec Doctrine, on se retrouve à vouloir connaitre quelle est la vraie requête faite en base. Voir ici. Réponse officielle : on ne peut pas. On ne peut pas voir les requêtes qui sont envoyées au moteur de base de données. Mais si continuez de lire, arrêtez de pleurer de rire ! Allez vous chercher un mouchoir, essuyez-vous les yeux et revenez.
  • Doctrine est censé simplifier la vie en proposant un modèle d’héritage. Exemple de ce que j’ai réalisé : une personne est la classe de base, et de là descendent les professeurs et les étudiants. Pourtant il est lourd. Très lourd. Très (très³²) lourd. Tellement lourd, que même sur la documentation officielle ils reconnaissent que Doctrine est lourd. La preuve sur la documentation officielle. En fait il est censé simplifier la vie du développeur, mais avec Doctrine il faut une machine énorme pour pouvoir faire tourner la moindre requête un tant soit peu complexe.
  • Pire. Encore bien pire (si c’est possible !). Si, comme moi, vous voulez utiliser des requêtes comprenant des calculs de distance, il vous faudra utiliser des fonctions mathématiques et là, de base, Doctrine ne connait rien, et il vous faudra passer quelques heures à installer un bundle dans votre installation, en modifiant pas mal de fichiers un peu partout. Si, là aussi, essuyez vos larmes de rire et lisez bien ce qui suit, car c’est vrai : il est impossible de faire immédiatement cette requête sous Symfony : "SELECT COS(5) as distance;". Non non ça n’est pas une blague, c’est du sérieux. Voir tout mon article détaillé ici.
  • Symfony est tellement complexe qu’il faut absolument avoir un débogueur intégré tel que xdebug et pouvoir faire du pas à pas dans un environnement tel que PhpStorm qui donne la possibilité de suivre tout, avec la pile d’appel. Rendez vous compte : pour développer un site Web simple, des frameworks comme symfony sont tellement complexes qu’il faut obligatoirement pouvoir faire du pas à pas. Ce sont des experts Symfony qui me l’ont expliqué. Sur le coup j’ai sincèrement (honnêtement, ce n’est pas ironique, c’est véridique) cru que c’était une blague. Php est tellement simple et fluide quand il est bien développé que je n’ai jamais eu à utiliser de débogueur pas à pas en plus de dix ans ! Et ma dernière prestation était en tant qu’expert Web chez Business & Décision, prestation pour la banque, et on n’a jamais eu besoin de faire du pas à pas ! D’ailleurs pourquoi je me justifie ? N’importe quel béotien doit se douter de ça…

Je n’ai pas le temps de lister toutes les autres choses qui m’ont fait perdre un temps fou. J’ai vendu un site que je comptais faire en maximum dix jours, et je l’ai fait en un mois. Symfony était tout bonnement un mauvais choix.

En conclusion :

Symfony est censé faire gagner du temps mais en pratique, on est obligé d’apprendre la globalité de tout le framework et au final on ne gagne absolument pas de temps, et bien pire : si le projet est petit, il faut à tout prix éviter des usines à gaz telles que Symfony.

Pour la petite note, les personnes qui m’ont sous traité le projet – qui tourne bien actuellement – ont été déçues parce que je n’ai pas tenu mes délais, et que mes premières livraisons n’étaient pas de bonne qualité – alors que je « semblais » compétent. Je ne jette pas tout sur Symfony, mais bon sang quelle grossière erreur de ma part ! Pour vous donner une idée de comparaison : j’ai terminé en 3 jours un site qui devrait être mis en ligne incessamment sous peu : un site spécialisé la constatation fiable de sites Web. Il contient :

  • Un formulaire d’inscription contenant tout ce qu’il faut (CSRF protection, re-Captcha etc) ;
  • Un CSS full responsive ;
  • Un blog WordPress (évidemment full responsive) ;
  • Un outil complet de capture d’écran basé sur du Webkit (très gros boulot) ;
  • Du code pour gérer un multi-partenariat en marque blanche ;
  • Du templating Smarty pour modifier l’habillage rapidement ;
  • Une documentation entièrement compatible PhpDocumentor ;
  • Une classe (assez longue) pour le traitement des images (archivage, signature chiffrée etc) ;
  • Un ORM qui :
    • ne fait des requêtes que quand c’est nécessaire,
    • fait des requêtes en SQL pur. Ouf, je respire, des heures entières de gagnées.
    • délègue au maximum à la base de données, ce qui est absolument vital pour avoir une application stable, rapide et pérenne sur le temps.
  • Une classe simple d’envoi de mail, avec la possibilité d’envoyer le texte alternatif (= si jamais le client ne peut pas lire du HTML, on peut préciser le texte). Merci PHPMailer, un outil simple, ultra facile d’utilisation, et utilisé dans ma classe, finit par un code ainsi :
    $mail = new ObjetMail(
        EMAIL_DEFAUT_FROM,
        EMAIL_DEFAUT_FROM_NAME,
        EMAIL_DEFAUT_REPLYTO,
        EMAIL_DEFAUT_REPLYTO_NAME,
        $email,
        'Capture bien prise',
        /*... Texte HTML ...*/,
        /*... Texte alternatif ...*/
    );
    try {
        $mail->send();
        array_push(
            $this->_TabResult,
            $this->trad->get(
                'mail_envoye_en_attente_confirmation'
            )
        );
    } catch (Exception $e) {
        $this->addTabErr(
            $this->trad->get('err_envoi_email')
        );
        $ok = false;
    }
  • Tout est tracé et archivé, aussi bien en base que dans les captures d’écran, et tout est prévu pour une grosse évolution : un compte, ce compte pourra avoir plusieurs emails, plusieurs captures, toutes les connexions – réussies ou échouées – sont déjà tracées, ils pourront avoir une ou plusieurs adresses etc.

Faire la même chose avec Symfony ? Je vous laisse estimer le temps de faire les estimations, le cahier des charges, le devis, le développement, mais attention, grâce à Symfony vous allez gagner énormément de temps : Symfony peut générer le CRUD pour l’administration en ligne de commande, regardez ici. Oulah que de temps gagné ! Sachant que je génère un custom getter-setter en 3 touches avec vim, même s’il y a plusieurs centaines de champs, et plusieurs dizaines de tables, je ferais ça « à la main » au maximum en une journée… enfin bon en comparant avec Symfony je peux dire sans éxagérer : sans Symfony, une journée de perdue, mais dix d’économisées ! Mais pourquoi je continue à essayer de prouver que Symfony ne fait jamais gagner de temps, moi ? Même ces personnes expertes Symfony ont décidé de le laisser tomber et de n’utiliser que Silex pour tous leur nouveaux projets à moins qu’ils n’aient vraiment besoin de choses spécifiques à Symfony… et personnellement je n’arrive pas à voir ce que Symfony a de si spécifique dont on ne peut pas se passer 🙂 … A l’inverse, je vois vraiment toutes les raisons pour lesquelles on peut se passer de Symfony.

30 comments

  1. Julien

    Je n’ai pas l’expérience que tu as avec Symfony, et pourtant je comprends tellement bien ce que tu veux dire.

    En ce qui me concerne, je n’utilise pas Symfony que je trouve bien trop complet et complexe. Je préfère me faire mon propre menu à la carte, avec Silex, Propel, Twig et Symfony\Console.

    J’ai osé essayer utiliser le FOSUserBundle… Quelle erreur. J’ai du passé des erreurs à parcourir le code pour comprendre comment ça fonctionnait. J’ai d’ailleurs eu à installer xdebug pour l’occasion !

    Bref, Symfony c’est bien, il propose quantité d’outils qui peuvent s’avérer pratiques. Mais à utiliser en tant que tel pour un projet, je n’en voyais pas l’intérêt et tu as confirmé mes craintes.

  2. Dededede4

    Salut !
    Je suis développeur web freelance et depuis que j’ai eu le courage de me mettre à symfony, je ne regrette pas mon choix.

    Il faut savoir que symfony est difficile à prendre en main. C’est un investissement en terme de temps.

    Le temps sera gagné, oui, quand vous maîtriserez symfony et les bundles de base.
    Vous le gagnerez surtout au niveau de la maintenance, du travail avec les collèges, et aussi à la conception du site, bref partout.

    Un exemple ?
    On souhaite faire un livre d’or avec connexion / inscription.

    Ça va se résumer, en gros :
    1- Mettre la template dans app/Ressources/views/base.html.twig
    2- Mettre le mot de passe BDD dans parameters.yml
    3- Installer fosUserBundle ( qui s’occupe d’installer sommairement la page login, inscription, rappel du mot de passe, validation du compte par mail )
    4- En quelques minutes grâce aux générateurs, créer le LivreDorBundle avec une Entité Message, le FormType.
    5- Faire les routes / pour l’accueil ; /nouveau-message ;
    / pointant vers un controller qui fait LivreDorBundle:Message ->findAll() et nouveau-message qui se contente d’afficher le formulaire.

    Voilà, y’a pas mal de message. On veut paginer le truc ?
    On installe knpPaginator et en 8 lignes on l’a !

    On veut créer une page qui permet de lire un seul message ?
    On fait une route du type : /lire/{id}
    Et dans le controller : function lireAction(Message $Message){ // On a une entité message de prêt à envoyer à la vue, twig qui fait son {{ Message.Username }}…

    Bref, perso je garde.

    • Olivier Pons

      Bonsoir,

      Je ne vois pas en quoi, par rapport à tout ce que tu as cité, tu gagne du temps par rapport à un développement from scratch + Twig (ou Smarty) + règles de réécriture.

      • D’ailleurs, en tant que spécialiste des règles de réécritue Apache (cf mon profil et mes réponses acceptées sur stackoverflow) le routing symfony n’est ni plus ni moins qu’un détournement de règles de réécriture Apache (on peut générer ces règle en ligne via, par exemple « php app/console router:dump-apache -e=prod --no-debug« ). Donc gain productivité sur toutes les routes dont tu parle, ici = 0 minutes.
      • LivreDorBundle:Message ->findAll() euh… quelle différence avec (je résume) PDO->("SELECT * from LivreDor") ? Gain productivité = 0 minutes.
      • Installer le FOSUserBundle + configuration totale = une heure max. Développement à la main avec CSRF des mêmes fonctionnalités : une après midi grand maximum. Trois heures de gagnées pour Symfony.
      • Installer KnpPaginator ? Une heure max. Le même sur Twig solo ou Symfony ? Développement à la main des mêmes fonctionnalités : une après midi grand maximum. Trois heures de gagnées pour Symfony.

      Ok pour un projet comme ça, sans aucune évolution : 6 heures pour symfony.

      Maintenant :

      • gestion de deux profils : admin et simple lecteur (qui peut laisser des messages) : symfony : installation PUGXMultiUserBundle. Configuration totale. Dérivation des classes. Mise en place du routing. Même en connaissant, minimum deux heures. Fait à la main (et je sais de quoi je parle vu que j’ai fait les deux !) : maximum une heure. Moins une heure pour symfony
      • Optimisation de quelques requêtes un peu lourdes à être exécutées : quatre heures pour symfony, sachant que comme je l’ai dit (preuve à l’appui) on ne peut pas voir comment Doctrine optimise et envoie les requêtes. Donc je reste gentil avec quatre heures. A la main : une heure grand max. Moins trois heures pour symfony
      • Tu veux inclure une gestion d’adresse et de distances ? Deux heures minimum et encore, en suivant mon tutoriel sur le lien que j’ai donne dans cet article. A la main : rien à faire, vu qu’un « SELECT COS(5) » fonctionne directement en SQL.Moins deux heures pour symfony
      • Tu veux développer sous Windows ? Avec WAMP, sur Windows Seven, mon Core i5 3.10Gz / 16 Go RAM indice de performance 7,7 sur Windows, une page met en moyenne 9 secondes en mode debug. Allez on fait un calcul gentil : 200 modifs = attente inutile de 200 * 9 = 30 minutes de perdues contre 0 secondes (oui, c’est instantané). D’un autre côté c’est normal, Symfony calcule tout, et ce tout le temps. Donc forcément, même quand tu ne veux pas tout regarder (temps d’exécution des queries, temps de génération du cache, temps de mon zboob) eh bien Symfony le fait. 30 minutes de perdues = deux heures et demie par semaine. Deux jours complets de développement perdus pour rien sur un projet de un mois. Disons que je compte uniquement sur une semaine.

      Voilà. Rien que là, sans avoir exagéré, pour un projet basique comme le tiens, avec la moindre évolution, Symfony perd déjà une demi journée par semaine de productivité.

      Et encore : j’ai été très gentil sur le temps de refresh lorsqu’il régénère le cache, car je n’ai pas compté toutes les fois où il faut supprimer à la main les fichiers de cache car il ne refait pas le cache, alors que les fichiers ont été modifiés et qu’on perd dix minutes à pas comprendre pourquoi la modif qu’on vient de faire ne fait rien…

      Bref Symfony ça reste comme je l’ai dit : pour les débutants qui pensent y arriver rapidement. Mais c’est un miroir aux alouettes : ne vous y trompez pas, si vous commencez en Php vous allez galérer avec Symfony dès qu’il faudra un peu pousser les choses.

      Pour les développeurs rapides et expérimentés, regardez du côté de YAF. Ca c’est du vrai framework MVC, avec une rapidité fulgurante. Même chose côté Phalcon.

      • Dededede4

        Je vais comparer ce que tu me dis par des situations réelles rencontré dans le cadre d’un projet perso : webmediacompany.tv

        Le routing symfony n’est ni plus ni moins qu’un détournement de règles de réécriture Apache
        Admettons que tu as /admin/creer ; /admin/editer ; /admin/machin … avec les routes tu peux modifier les path facilement, et sans a avoir à modifier les .
        Je dois changer /profil/{id} par un username. Bah je vais dans le routing, je change la ligne /profil/{id} par /profil/{username}, c’est fini je n’ai rien d’autre à faire.
        LivreDorBundle:Message ->findAll() euh… quelle différence avec (je résume) PDO->(« SELECT * from LivreDor ») ?
        Sur mon site, je devais écrire un truc tout con : « Ce site comporte 80 vidéos ». Et je m’étais dit comme toi, pourquoi se faire chier à créer un repository et tout alors qu’il suffit de faire la req. Bref, je modifie le repository, ce qui me force à lire ce qui a déjà été codé et me rappelle que ce n’était pas aussi simple : il fallait aussi vérifier si la date de sortie de la vidéo est passée, si le compte qui a posté la vidéo est validé, et que la saison est supérieur à 0. Comme il y avait dans le repository la fonction qui filtre ça, je n’ai pas eu à coder plus qu’initialement prévu, mais j’ai évité d’afficher un chiffre faussé.

        « gestion de deux profils : admin et simple lecteur (qui peut laisser des messages) : symfony : installation PUGXMultiUserBundle »
        hein quoi comment ?
        Tu inscris ton admin via le formulaire d’inscription.
        Tu lui donnes le role administrateur :
        php app/console fos:user:promote pseudoAdmin ROLE_ADMIN

        Puis dans la vue {% if is_granted(‘ROLE_ADMIN’) %}Supprimer le message{% endif %}
        Tu dis dans la config de symfony que seul l’admin peut accéder aux urls qui commencent par /admin ; et tu peux faire /admin/supprimer/message/{id}.

        « Optimisation de quelques requêtes un peu lourdes à être exécutées : quatre heures pour symfony, sachant que comme je l’ai dit (preuve à l’appui) on ne peut pas voir comment Doctrine optimise et envoie les requêtes »
        Je ne sais pas optimiser les requêtes.
        Si tu veux voir ce que doctrine envoie à la base de donnée, tu cliques sur le profiler ( la barre en bas de ton app_dev.php ) à l’endroit où il y a le nombre de requête et le temps.

        Ça te liste toutes les requêtes et le temps pour chacune d’elles.

        Tu veux inclure une gestion d’adresse et de distances ? Deux heures minimum et encore, en suivant mon tutoriel sur le lien que j’ai donne dans cet article. A la main : rien à faire, vu qu’un « SELECT COS(5) » fonctionne directement en SQL.Moins deux heures pour symfony
        Ouais, ça c’est chiant. Perso c’est RAND(), LIKE que je n’arrive pas à utiliser simplement. Il peut peut s’activer…
        Je dois rajouter sur WMC un système de petites annonces géolocalisés, je vais m’orienter vers fos elasticabundle.

        une page met en moyenne 9 secondes en mode debug.
        Hein quoi ? y’a un problème là, t’es sûr que t’as pas un script qui charge pas ou un truc genre ? Chez moi le dev est fluide, presque autant que la prod. (Je code sous debian)

        « J’’ai été très gentil sur le temps de refresh lorsqu’il régénère le cache » ouais, perso je fais rm -r app/cache/* ; je sais pas si c’est une bonne pratique mais c’est très rapide.

        • Olivier Pons

          Bah je vais dans le routing, je change la ligne /profil/{id} par /profil/{username}, c’est fini je n’ai rien d’autre à faire.

          Et en routing Apache, FYI, on ne fait aucun effort supplémentaire, non plus 😉
          … mis à part que Apache (et crois en mon expérience, j’ai backporté un module Apache en C) est 200 fois plus rapide (en moyenne) que le pseudo code compilé de Php.

          Sur mon site, je devais écrire un truc tout con : « Ce site comporte 80 vidéos »….

          Si tu veux voir ce que doctrine envoie à la base de donnée, tu cliques sur le profiler ( la barre en bas de ton app_dev.php ) à l’endroit où il y a le nombre de requête et le temps.

          Es-tu bien sûr qu’il y a la requête ? Je cite (par des gens bien plus compétents que moi) : stackoverflow ici. ce n’est pas la requête préparée qu’on veut, c’est le vrai SQL envoyé. Le vrai. Je cite :

          Doctrine is not sending a « real SQL query » to the database server : it is actually using prepared statements

          Enfin, ce que j’ai adoré :

          Je code sous debian

          Merci \o/
          Enfin un qui a compris 😉

          Moi aussi je suis sous Debian, mais je suis un bon gamer qui doit souvent revenir sous Windows, même si pas mal de jeux (y compris Dota 2) commencent à fonctionner super bien (voire mieux) sur le couple Ubuntu/Steam. Donc je veux pas rebooter entre deux pauses… donc je suis resté sous Windows, et je me demande comment font les gens sous Windows (débutant ou pas, on s’en moque, les gens… tout court).

          Merci à toi pour ton commentaire et encore une fois : oui, il fait gagner du temps, mais là où beaucoup pensent en perdre « un peu », en fait, ça détruit tout parce que « vu de loin » en faisant les comptes globaux, Symfony ne fait pas gagner de temps. Twig, oui, Smarty, oui. Pas Symfony. Je ne lâcherai jamais le morceau !

          • Dededede4

            Ok !

            Et en routing Apache, FYI, on ne fait aucun effort supplémentaire, non plus 😉
            … mis à part que Apache (et crois en mon expérience, j’ai backporté un module Apache en C) est 200 fois plus rapide (en moyenne) que le pseudo code compilé de Php.
            Quand je veux dire « Y’a rien a faire », c’est qu’il n’y a pas besoin de modifier un ->findById() en findByUsername() vu qu’avec le ParamConverter c’est automatique.

            Sur ce, je vous laisse 😉

  3. Shine-neko

    Soit tu es complètement mauvais en php soit tu n’as pas lu la doc de Symfony ni de Doctrine. Quel est le but de ton article justement ? faire des commentaires sur quelques choses que tu n’a visiblement RIEN compris ?.

    Bon je crois que bon ça ne mérite pas de commentaire mais je te laisse juste lire
    http://www.slideshare.net/rob_knight/object-relational-mapping-in-php
    http://fr.openclassrooms.com/informatique/cours/programmez-en-oriente-objet-en-php/l-hydratation

    Mais tes commentaires du Doctrine MAIS WOW …

    Juste pour te dire que si tout n’est pas entièrement faux. T’as quand même rien compris à Symfony. Tu peux pas parler comme tu le fais.

    • Olivier Pons

      Bonjour,

      J’ai validé ton commentaire en essayant de supprimer ce qui n’est pas constructif… mais à part le lien vers des choses que je connais – et compris – depuis longtemps (tu n’as jamais lu mon blog), il n’y a aucune explication sur le « pourquoi ce que je dis est stupide ». D’ailleurs si c’est le cas, je supprimerai mes bêtises, en m’excusant.

      Question « hydratation », j’ai bien relu en détail le lien que tu m’as donné – et le partage, un grand merci, mais je ne change absolument pas de point de vue : ça fait plus de vingt ans que ça existe, et un benêt a décidé de créer ce mot pour le fun, et tout le monde a suivi. « Hydrater » un objet. OMFG…

      Je ne change pas de discours : Symfony part d’un bon sentiment et essaie d’atteindre quelque chose d’idéal mais en pratique, tu perds trop de temps, point à la ligne.

      Je vais me justifier – même si je n’ai pas à le faire.

      • Ecris un accès et une gestion complète ORM en C pur, à une base de donnés BerkeleyDB puis tu me diras si on a compris – ou pas – l’ORM.
      • Ré-écris entièrement tout un framework quatre fois pour en arriver à une organisation à peu près potable (cf ici).

      Cela fait déjà deux ans. Note que j’ai ré-écrit pendant plus de six mois ce framework, que j’avais ré-écris trois fois étalé sur une période de huit ans. L’année dernière, j’ai voulu le laisser tomber et utiliser plein de frameworks, et les tester à fond, en partant sur le principe – indéniable – qu’il y a plein de gens plus intelligents que moi ont fait des choses mieux. Donc je pense que je sais de quoi je parle.

      Ils sont tous pareils, même les derniers : par exemple FuelPhp a copié collé Symfony en plus mauvais (mais pour voir faut carrément analyser le code donc ici aussi les débutants diront qu’il est mieux). Je le dis et le redis : tous les gros frameworks – à part le YII et CakePhp, sont des usines à gaz. Voici le meilleur lien possible, renseigne toi bien : http://www.techempower.com/benchmarks/

      Je dirais l’opposé de toi : tu n’as pas assez d’expérience pour te rendre compte à quel point, même si on gagne du temps sur certaines choses, on en perd sur d’autres, et au final, Symfony n’est pas rentable. Je ne suis pas le seul, j’ai travaillé avec des experts Symfony, des vrais, des durs, qui sont partis de la v1 et ont tout suivi presque jour après jour et le connaissent par coeur. Eux-même disent qu’ils le laissent tomber et n’utiliseront plus que Silex (cf lien sur mon article), sauf si vraiment il leur manque un truc qu’il n’y a que dans Symfony.

      Merci encore pour tes liens, j’espère qu’ils apprendront des choses à tous les gens qui lisent ce blog.

      Olivier – HQF Development

  4. lolo

    Concernant le traitement des formulaires, il me semble qu’il faille passer par les events sur les formulaires.cf: http://symfony.com/fr/doc/master/cookbook/form/dynamic_form_modification.html#generation-dynamique-pour-formulaire-soumis
    Concernant le FOSUserBundle, tu peux avoir plusieurs types d’utilisateurs ayant des rôles différents: rôle utilisateur, rôle modérateur, rôle admi ou même encore un rôle superadmin si ton appli le nécessite.
    Sensio veut que tout passe par les services pour assurer une réutilisabilité du code, mais on peut aussi coder à l’arrache dans les contrôleurs ou tout autre classe à part, cela reste du php.
    Doctrine reste un ORM, une abstraction entre la base et tes entités, cela sert uniquement si tu veux un jour changer de base de données, si tu es resté dans les clous avec les query builder, cela ne posera aucun problème. Tu peux néanmoins utiliser des NativeSql lorsque tu atteins les limites du querybuilder(cf: http://docs.doctrine-project.org/en/latest/reference/native-sql.html).
    Symfony est à proscrire si tu as une échéance proche et que tu ne connais pas le framework, il faut un temps certain sinon un certain temps pour l’appréhender(lire et relire la doc, et ne pas prendre pour argent comptant les exemples ou tutos piochés sur le net car le framework évolue tous les jours: ce qui était valable pour la version 2.0,2.1 ou 2.2 peut avoir changé puisqu’on en est rendu à la 2.4). Symfony est certainement rentable sur de gros projets ou pour des dévs qui ont l’habitude du framework.
    Par contre, je suis d’accord avec toi concernant le fait qu’il n’est pas du tout adapté au développement sous Windows (c’est affreusement lent en dév).
    Concernant les autres frameworks qui ne soient pas trop root, cela va de parsimony.mobi à bolt.cm … juste histoire de documenter. Je vais jeter un oeil à ton yaf que je ne connais pas. Bonne journée!

    • Olivier Pons

      Merci beaucoup pour ces commentaires très constructifs. Tu as peut être raison pour des gros projets.

      Tu peux néanmoins utiliser des NativeSql

      .
      Là il faut pratiquer pour voir que c’est faux (pas ce que toi tu dis, mais ce que eux disent) : doctrine analyse tout de même systématiquement tout. Donc tu ne peux absolument pas du tout faire du vrai native SQL (c’est pour ça que j’ai fait mon article sur les fonctions basiques qu’il ne connait pas : COS(), SIN() etc.)
      Merci pour ton commentaire, car j’en ai filtré beaucoup qui m’insultaient sans aucun argument valable.

  5. eric

    Bonjour, je pense que tu dis cela parce que tu ne maîtrise pas bien symfony. En fait symfony n’a aucune qualité si on est débutant.

  6. Lallement Thomas

    En lisant ce billet je me rends bien compte que tu n’as rien compris a Symfony ! Tout est dans la documentation. Je ne vois pas en quoi une Entité devrait accéder a son repository pour persister un fichier en DB. Il faut simplement que le fichier soit hydraté lors du Post (par un Form listener ou plus simplement au niveau du controller, si ça te semble trop complexe…) puis persisté. Je ne vois pas en quoi des Hacks sont nécessaire ici.

    Je développe l’application qui sert à l’organisation des Présidences Européenne depuis 2005 (voir http://www.pt-consulting.eu/fr/novento) et on a décidé de tout réécrire sous Symfony dernièrement, alors qu’on avait une solution qui a pris des années a se compléter. Verdict après 5 mois de Dev à 2 personnes : on a une plateforme quasi opérationnelle très propre, maintenable, rapide et d’une stabilité exemplaire. C’est pourtant une application qui contient un tas de fonctionnalités et de modules complexes :
    – logistique (réunions, programmes, hôtels et chambres dispo par type de participant : chef de délégation, média, fournisseurs, convois de véhicules, cadeaux, etc.)
    – formulaires d’inscription de participant avec Flow et champs configurables par type de participant et par réunion en ligne
    – accréditation suivant des workflow spécifiques configurables
    – édition WYSIWYG et génération de badges en ligne
    – gestion des contrôles d’accès par zones avec techno RFID et QRCode
    – historisation de !!toutes!! les action d’édition (même des modifications liées a des valeurs de champs éditables)
    – statistiques sur l’ensemble des modules
    – et énormément d’autres choses

    Pas un seul Hack n’a été nécessaire a la mise en place de l’ensemble et pourtant il y a un paquet de choses sur lesquels on avait des incertitudes auquel on a fait face simplement grace a Symfony, Doctrine et Imagine pour la gestion des images ;).

    En résumé je dirais quel bonheur de travailler sous Symfony. J’avoue que j’ai travaillé avant en Java sur Spring et JPA Hibernate et à mon sens Symfony et Doctrine en reprennent tout le meilleur avec une productivité boosté x5 minimum.

    • Olivier Pons

      J’ai laissé ton commentaire, car il semble constructif – en modifiant juste la première phrase, ne m’en veut pas 😉

      Historisation de toutes les action d’édition

      Je comprends que ce soit une nécessité : mon framework prend ça en compte pour l’intégralité des tables : quelles que soient les modifications sur des tables (les R,U,D du principe « CRUD »), tout est entièrement archivé et rien n’est jeté, tout en laissant une rapidité des requêtes en lecture à leur vitesse maximale.

      Pour information, il suffit de mettre en place un bon trigger dans MySQL (même si cette BD est incroyablement mauvaise comparée à PostGreSQL question triggers (cf ma question ici qui a pourtant deux ans d’âge et rien n’a changé), elle arrive au moins à faire ça), il n’y a besoin d’aucune ligne de code supplémentaire. C’est uniquement pour ressortir l’historique qu’il faut une requête.

      Et effectivement, je comprends très bien une chose : peu importe où tu vas, si tu as fait auparavant du Spring et JPA Hibernate, ça ne peut être que mieux ! 😉

  7. Yann

    Salut,

    Je débute sous Symfony2 et je comprend ton post rageur car on peut passer des heures à faire un truc simple quand on a pas l’habitude. Donc effectivement on perd énormément de temps… au début ! Je pense qu’une fois maitrisé on gagne beaucoup de temps, on se prend moins la tête et surtout le code est beaucoup plus propre et structuré qu’en php basique.
    La multitude bundles disponibles est également très pratique.
    Je trouve que tu éxagères largement mais je comprend que c’est frustrant de passer énormément de temps pour faire des choses qu’on savait déjà faire avant avec du vieux php tout moche de l’an 2.

  8. Tugudu

    Symfony 2 n’a jamais été conseillé pour des petits projets. De même qu’en général, utiliser n’importe quel framework pour un petit projet n’est pas une chose à faire sans y avoir préalablement réfléchis.

    Tout les désavantages cités font partie de la formation, l’acquisition de compétence. Tout comme pour n’importe quel framework un tant soit peu conséquent, après le 5ème projet sur le même framework, l’histoire sera différente.

    Se lancer dans un framework n’est pas une chose à faire à la légère. Il faut être prêt à se casser les dents pendant plusieurs mois dessus, et avoir la garantie que le temps perdu sera ensuite rentabilisé !

    Enfin, si le problème persiste, tu n’es pas forcé d’utiliser Doctrine, Twig, FOSUser. Ce ne sont des bundles qui complètent le framework, et non pas le framework en lui même. Il existe une quantité d’alternatives, respectivement : Propel, PHPTal, Sonata. J’en passe et surement des plus appropriés.

  9. pisco

    Olivier bonsoir à toi, je suis intéressé par le métier de développeur je n’ai aucune connaissance là-dessus ni même jamais fait la moindre ligne de programmation pure. Pourrais-je avoir ton skype ou adresse mail afin d’avoir les conseils d’un pro pour commencer sur de bonnes bases.

    à bientôt j’espère

  10. LC

    Bonjour,

    Je pense que vous êtes passés à côté de l’essentiel. La plupart de vos arguments montrent que vous n’avez pas assimilé un certain nombre de principes, ou peut-être n’avez-vous simplement pas compris à quoi servait l’outil. Ce qui me surprend d’autant à la vue de votre expérience.

    Symfony est un outil certes compliqué, mais pas complexe, au contraire. Il vous faudra du temps avant de le maîtriser et d’être productif, c’est un investissement sur le long terme que tout le monde ne peux pas prendre.

    Oui, écrire des choses simples est plus long avec Symfony si vous ne maîtrisez pas l’outil. D’où le besoin de bidouiller pour arriver à faire ce que l’on veut.

    Bref, j’ai l’impression donc que vous comparez un vélo avec une navette spatiale, sans jugement de ma part sur la haute technicité de l’un par rapport à l’autre. Je pense que moi aussi je pesterai si je devais démarrer une navette spatiale tous les matins pour conduire mes enfants à l’école…

    PS: quand vous dites, dans votre conclusion :
    Un ORM qui :
    ne fait des requêtes que quand c’est nécessaire,
    fait des requêtes en SQL pur.

    J’ai un peu peur. Un ORM qui fait des requêtes en SQL pur ? Doctrine ne cause pas à la base de données en SQL alors, on m’aurait menti ?

    • Olivier Pons

      Bonjour,

      Merci beaucoup pour ce commentaire constructif, j’aime la comparaison avec la fusée, c’est très réaliste.
      Quand je parle de faire des requêtes simples et lisibles je le mets en opposition au pseudo langage qu’est DQL, qui n’est rien d’autre qu’une surcouche à du SQL, ce qui ne sert absolument à rien. Enfin si, l’objectif d’origine était de faire du cache entre le DQL et la requête SQL même. Mais comme je l’ai déjà dit dans un autre post, un système correctement pensé n’a besoin de cache qu’en frontal et en base de données, donc tout autre type de cache qui s’avère utile montre une seule chose : c’est que le système n’est pas bien pensé ou n’a pas évolué dans des mains de bons techniciens (ce qui est souvent le cas aujourd’hui et qui peut se justifier pour des grosses entreprises qui font tout vite et mal, mais j’ai la chance de ne pas être dans ce cas là).

      Donc passer du temps à apprendre DQL pour, au final, voir que c’est plus lent que du SQL pur, c’est comme d’apprendre à cuisiner d’un autre façon pour faire uniquement des repas plus mauvais et moins évolutifs : c’est totalement inutile – sachant que dans le cadre de DQL, on n’apprend rien alors que dans l’image que je viens de donner on peut éventuellement apprendre de nouvelles choses.

  11. LC

    Bonjour,

    par retour, merci pour votre commentaire constructif, bien plus posé que votre laïus initial.

    Pour le DQL, je concède sans peine que ça n’a pas la souplesse du SQL natif. Qui plus est, cette « surcouche » éloigne le développeur de la « matière » qu’il est censé modeler, en l’occurrence un SGBDR via du SQL. D’où la possibilité de dérive technique.

    Mais je pense que c’est ainsi que va l’informatique. Aujourd’hui, les langages de haut niveau sont la norme ; les développeurs ne se soucient plus des optimisations mémoires, des cycles d’horloge… Ne savent même plus comment fonctionne un processeur ni même TCP… SQL ? Plus besoin de s’embêter avec ça quand on fait du web à fort trafic : on mise sur des caches HTTP, et Redis est magique pour stocker des données. Plus besoin de connaissances « bas-niveau ».

    Je suis de la vieille école, encore attaché à des choses plus « bas-niveau », mais pourtant bien moins que ceux de la génération avant la mienne. Mais les « jeunes » me surprennent encore et toujours, quelque fois par leur fougue imbécile, quelque fois par leur talent.

    Je terminerai donc juste par cette célèbre citation de Mark Twain : « Ils ne savaient pas que c’était impossible, alors ils l’ont fait »

  12. Ricotchet

    Ton coup de gueule m’a fait un bien fou : je ne suis pas le seul à penser que Symfony c’est chiant ! Je me suis mis à Symfony juste pour pouvoir espérer trouver du travail en tant que développeur car apparement c’est le Framework phare au vus des annonces d’emploi !
    J’ai effectué une formation de développeur en 2013-2014 (bac +2) et je voulais rajouter une flèche à mon arc, mais là j’avoue que j’en ai marre : on passe son temps à éplucher des tutos, configurer et encore configurer et toujours configurer des machins, et faire des copié collé d’exemples ! Moi qui aime coder c’est super frustrant ! Après faut être honnête je n’ai pas ton expérience ni ton acquis, coder une application avec gestion des users, etc me prendrait un temps fou … mais ce serait que du bonheur 🙂 ! alors que là je fais le site Internet d’un ami pour me « faire la main » et je galère mais grave !! Et je ne prend aucun plaisir !
    Ceci étant dit je veux bien croire ceux qui dise que c’est dur au début (et longtemps) mais après c’est plus efficace que la méthode traditionnelle .. mais bon d’ici là …
    Voilà ça fait du bien .. je vais essayer de m’y remettre maintenant 😉
    Bonne continuation à tous !

  13. florian

    Un peu déçu par l’article. Vous êtes un de mes anciens professeurs mais je m’attendais a mieux que ça. Maintenant je suis freelance Symfony. La courbe d’apprentissage du framework est très longue il faut bien un an et demi pour arriver a faire ce que l’on veut dans les règles de l’art.

    Mais pour des gros projet c’est idéal. pour de petits projets ce n’est pas idéal non, il y a plein de CMS qui font déjà le boulot, et puis il y a de bon petit Frameworks fait pour ça, un light symfony -> silex, codigniteur zend etc.

    J’ai travaillé sur des projets avec des budgets de plusieurs millions d’euros et je peux assurer que sans ce framework c’est mission impossible. Enfin déçu par des adjectifs comme « lamentable » etc. Symfony est un framework de hacker passionés. Il tire clairement le monde Php vers le haut mais n’est pas destiné à tout le monde et à tout les projets.

    Pour moi créer un service de crop maintenant c’est simple m’amuser et hacker le framework en permanence c’est devenu un jeu.

    Enfin bref je ne savais pas que vous aviez un blog.

    Actuellement je fais mon site et même si je suis pro Symfony je ne vais pas utiliser cmf qui est bien trop lourd mais un simple WordPress et si les plugins ne me conviennent pas je vais les hacker, c’est la philosophie que Symfony nous propose et je pense que vous ne l’avez pas compris mais comme souvent avec ce framework, ça passe ou ça casse.

    Bonne journée

    • Olivier Pons

      Bonjour Florian,

      Merci pour ces remarques. Je devrais juste dire en début d’article : si vous avez beaucoup d’expérience, lisez ce qui suit, sinon passez votre chemin.

      Mes adjectifs de « lamentable » et autres ne sont compréhensibles que par ceux qui ont fait du RAD, du vrai RAD. Pas du Zend ni du Php. Je fais une application complète, avec modèle de base de données, accès à la base, qui s’adapte à tous les écrans, et qui fonctionne sur Windows et Android, qui tourne en moins de 5 minutes avec Delphi.

      Non je n’exagère absolument rien. Tout ceux qui font du C# même si je n’en fait pas par principe éthique, peuvent dire la même chose. Je te mets au défi de faire de même avec Symfony. Alors quand on voit tous ces frameworks, Symfony y compris, qui, justement, essaient de combler – sans y arriver – le fossé de ratio de temps de développement en essayant de mettre en place certaines pratiques dans un monde – Php – qui n’est pas fait à l’origine pour ça, je m’énerve. Sur tes projets à plusieurs millions d’euros tu pense que ça n’est pas possible simplement parce que tu as découvert certains principes et que tu manque d’expérience, mais crois moi, avant Symfony, il y a eu beaucoup, beaucoup d’autres projets à plusieurs millions d’euros et ces derniers ont pourtant été menés jusqu’au bout.

      Je maintiens ce que je dis : Symfony est une grosse usine à gaz qui prône de bonnes pratiques, mais n’est utile que pour de très gros projets, et sa courbe d’apprentissage est trop longue par rapport à ce dont on a besoin dans 99 pourcent des cas lorsqu’on fait un site Web. Et si on veut quelque chose de plus léger (donc imaginer utiliser Silex) eh bien c’est qu’on est inévitablement dans du faux « sur mesure » c’est à dire CMS ou autre. Donc Silex est inutile, tout court.

      Bref je ne change pas : quand on n’a pas d’expérience c’est bien d’apprendre Symfony et les bonnes pratiques, comme tu le fais. Quand on a de l’expérience, il vaut mieux chercher à tout prix une solution qui utilise l’expérience qu’on a, parce que Symfony, au lieu d’apporter quelque chose de bien, fera inutilement perdre du temps.

      PS : je me suis permis de corriger au passage quelques unes de tes fautes d’orthographe…désolé…

  14. Matthieu

    Bonjour,

    Il y a énormément de choses incorrectes dans l’article, impossible de répondre à tout, alors je vais me concentrer sur les choses de base :

    – « Symfony prône les bonnes pratiques […] mais il échoue lamentablement. »

    Non : tu échoues lamentablement (désolé je réutilise tes mots). Ça n’est pas Symfony qui veut insérer un fichier en BDD depuis une entité, c’est toi. Et le problème il est là. L’approche de Symfony n’est peut-être pas ce à quoi tu es habitué et si tu essaye d’appliquer ton approche sur une autre… Bien sur que ça marche pas. Tu n’es absolument pas censé (dans le cadre de Symfony + Doctrine) intéragir avec l’entity manager et la BDD dans une entité. Donc c’est normal si tu dois faire des hacks pour faire ça…

    – FOSUserBundle […] « Exemple concret là aussi : il n’est fait que pour un seul type d’utilisateurs. »

    Non. Tu n’as pas compris comment les utilisateurs marchent dans Symfony. Ne rejette pas le problème sur le bundle.

    – « Et puis là le code qui fonctionne utilise getRequest(). Et le container. Moi j’en avais besoin dans l’entité, car c’est ici qu’on écrit les informations en base de données. »

    Non, ça n’est pas dans une entité qu’on fait ça. C’est normal après que tu fasse des hacks : ça n’est pas censé marcher comme ça.

    – « Doctrine est quelque chose… que je ne comprends pas. Il a été crée pour « optimiser » les requêtes. Déjà, rien que d’écrire ça, c’est inévitablement un non sens : on n’optimise pas les requêtes via du Php… »

    Tu es complètement à côté de la plaque : Doctrine n’est absolument pas fait pour « optimiser » les requêtes. Doctrine est un ORM de type Data Mapper:

    > The goal of the pattern is to keep the in memory representation and the persistent data store independent of each other and the data mapper itself.

    Donc le but c’est de te permettre d’écrire un modèle OO en le découplant de la persistence. Si tu n’as pas besoin de ça, alors n’utilise pas un ORM Data Mapper !

    – « On ne peut pas voir les requêtes qui sont envoyées au moteur de base de données. Mais si continuez de lire, arrêtez de pleurer de rire ! Allez vous chercher un mouchoir, essuyez-vous les yeux et revenez. »

    Mais WOW. Pascal explique que Doctrine utilise des « prepared statements » (ce que TOUT LE MONDE devrait utiliser pour des raisons de sécurité). Et grande nouvelle : ce sont des vrais requêtes SQL, c’est juste que les paramètres sont séparés pour éviter les injections SQL. Donc pour répondre à ta question : bien sur que si tu peux voir les vrais requêtes, d’ailleurs avec Symfony elle sont dans la barre de debug…

    – « Doctrine est censé simplifier la vie en proposant un modèle d’héritage. »

    OMG non non ! Doctrine n’encourage pas du tout ce modèle… Tu ne comprends pas cette lib et pourtant tu en dis du mal.

    – « J’ai vendu un site que je comptais faire en maximum dix jours, et je l’ai fait en un mois. Symfony était tout bonnement un mauvais choix. »

    Donc on est d’accord, Symfony n’est pas le problème, c’est toi qui as fait un mauvais choix… Commencer un nouveau framework sur un projet de 10 jours, c’est juste un très mauvais choix, Symfony ou pas…

    Bref cet article montre juste que tu n’as pas compris grand chose à Symfony, Doctrine et tous les bundles que tu as mentionné.

    À ta conclusion : « IL FAUT À TOUT PRIX ÉVITER DES USINES À GAZ TELLES QUE SYMFONY. » Je réponds :

    Est-ce que Symfony est simple au début ? Non.

    Est-ce qu’on doit utiliser Symfony partout ? Non.

    Est-ce que Symfony a des use-cases où il est utile ? Un très grand nombre de développeurs pensent que oui.

    La clé, c’est arriver à comprendre où Symfony sera utile et où il ne le sera pas. C’est un peu moins extrémiste comme point de vue. Parce que j’ai essayé d’utiliser Symfony une fois pour faire du café et ça a pas très bien marché, mais c’est pas pour autant que c’est un « lamentable » échec pour autant.

    • Olivier Pons

      Pour commencer, il faut savoir je forme sur Symfony soit des groupes professionnels et des étudiants, cela signifie qu’il est tout de même un bon outil. J’insiste même lourdement sur Twig qui est à mon sens le truc le mieux – et de loin – de Symfony. Donc, je le dis encore une fois : Symfony a plein de très bonnes idées théorique, et il est extrêmement bien fait dans ce sens, donc pour apprendre les bonnes pratiques et une organisation sécurisée, logique et pérenne, c’est bien.

      Maintenant, quand on a fini la théorie, et qu’on passe à la pratique, il n’existe aucun, absolument aucun outil qui convienne parfaitement à toutes les situations, et on est toujours, absolument toujours obligé de hacker pour arriver à ses fins, ce qui semble te choquer, alors que même s’il faut essayer à tout prix de l’éviter, c’est notre pain quotidien.

      Cet article est aussi amusant sur la forme que profond et intéressant sur le fond, je ne peux que conseiller à toute personne qui lit ma réponse ici de le lire : http://french.joelonsoftware.com/Articles/LeakyAbstractions.html

      J’avais fait une très longue réponse bien détaillée, mais me croyant sous vim, j’ai appuyé sur « Echap » et WordPress a supprimé ma réponse sans même en avoir gardé un brouillon… Désolé pour la réponse courte qui suit, mais je résume.

      Si tu relis bien toutes tes réponses, c’est la plupart du temps « on n’est pas censé faire le truc ainsi ». Et toutes tes réponses correspondent exactement à ce que j’explique dès le début : on n’est pas censé le faire ainsi, car ils ont des idées à la fois très bonnes, logiques et cohérentes. Mais en pratique, sur le terrain, quand tu construis une maison, si t’as besoin de faire un petit trou rapidement dans un mur pour pouvoir avancer et que t’as un tournevis sous la main, tu fais le trou avec alors que ça n’a pas été prévu pour ça. Mais ça fonctionne.

      Est-ce que tu as déjà lancé Symfony sous XDebug ? Fais le une seule fois au moment où il doit renvoyer une page, et dis moi quelle est la taille de la pile d’appel.
      Dis moi si tu trouve ça normal, et si ça facilite le déboguage.

      Je ne peux pas m’empêcher de te parler du FOSUser car je me suis peut être mal exprimé : ils expliquent que grâce à lui, on peut super facilement s’enregistrer, se connecter, qu’il y a une super astuce méga compliquée pour le CSRF qui est mise en oeuvre contre le piratage, que tu peux vendre des articles sur eBay pendant qu’il te fait le café et que tu te fais manucurer en gagnant le tournoi mondial de Dota 2. Concrètement parlant, le CSRF = deux lignes de code en Php. Si tu ne me crois pas je te les donnerai. Et par contre, à l’opposé totalement de ce qu’ils « vendent », on perd beaucoup plus de temps à le faire évoluer pour qu’il corresponde à une évolution minimale, que d’utiliser du code Php à la main dans Symfony – ou pas.

      La dernière chose qui m’a choqué venant de ton commentaire pourtant si technique, et sans fautes – bravo c’est vraiment très rare, il faut le souligner :

      Mais WOW. Pascal explique que Doctrine utilise des « prepared statements » (ce que TOUT LE MONDE devrait utiliser pour des raisons de sécurité). Et grande nouvelle : ce sont des vrais requêtes SQL, c’est juste que les paramètres sont séparés pour éviter les injections SQL. Donc pour répondre à ta question : bien sur que si tu peux voir les vrais requêtes, d’ailleurs avec Symfony elle sont dans la barre de debug…

      Deux choses :
      – Php fait ça nativement, et ce que tu explique qui semble si complexe, est simplement la base, et personne ne passe par autre chose : http://php.net/manual/fr/pdo.prepared-statements.php
      Pourquoi utiliser une grosse surcouche pour cela ? Aucun intérêt.
      – La barre de debug ? C’est une blaque ? Combien de sites Internet as-tu fait avec Symfony ? Je ne connais personne qui laisse la barre de débug même pour le développement, car en pratique, et encore une fois, tout ce que tu semble mettre en avant ressort plus de la théorie que de la pratique (donc j’aimerais vraiment que tu me dise combien de sites avec Symfony tu as réalisé, ainsi que leur taille, si cela ne te dérange pas), tu verrais que quand tu code, tu fais souvent quelques lignes et une des grandes forces de Php c’est le fait d’être interprété, dont hop tu rafraîchis ta page et tu vois le résultat. Si ta page met 5 secondes à être rafraîchie parce que Symfony analyse chaque requête, la durée de chaque requête, le temps d’exécution de chaque fonction, et j’en passe et des meilleures, tu perds à la fin de la journée des heures entières d’attente inutiles. Alors tu commence à désactiver ceci puis cela dans la barre de débug pour arriver à la fin où tu a presque tout enlevé et où tu te retrouve à faire l’équivalent du console.log() en JavaScript… et pour n’importe quel débutant, tu fais un tail -f en faisant un error log (http://php.net/manual/fr/function.error-log.php) et tu n’as plus besoin de toute cette surcouche qui te fait ramer toute ta page pour rien. Ici encore, j’insiste, il y a un bon sentiment à l’origine : on peut tout tracer et tout voir c’est génial ! Sauf qu’en pratique… bah on le voit bien, on n’a presque jamais besoin de tout ce que le mode débogue fournit.

      – « Doctrine est censé simplifier la vie en proposant un modèle d’héritage. »
      OMG non non ! Doctrine n’encourage pas du tout ce modèle… Tu ne comprends pas cette lib et pourtant tu en dis du mal.

      S’il te plait, explique moi clairement tout ce qu’explique cette page, si ce n’est pas de l’héritage de mapping :

      http://doctrine-orm.readthedocs.org/en/latest/reference/inheritance-mapping.html

      En tous les cas merci beaucoup pour ton commentaire, et un grand hourra à une très rare personne – si ce n’est la première, qui fait une très longue réponse sans faute d’orthographe. Bravo !

    • Olivier Pons

      Bonjour,

      Je connais bien Hibernate et il est excellent. C’est l’implémentation du moteur dans Symfony qui est totalement pourrie et bousille toutes les performances.
      De plus quand on veut déboguer pour savoir quelle est la requête qui est effectuée, on ne peut pas (j’ai mis le lien avec).
      Et ré-écrire le SQL sous une forme objet (= Doctrine), c’est d’une débilité qui n’a pas de limite, et qui restreint tout le code, justement, à Doctrine, et n’est plus du tout portable si jamais un jour vous décidez de changer de framework. Et si quelqu’un qui est très bon en SQL se joint à vous il ne pourra rien faire (le comble de la stupidité)… à part apprendre Doctrine…
      De plus Doctrine ne gère pas nativement des types que toutes les bases de données (ou presque ?) gèrent : le timestamp, par exemple. C’est simple : si on veut s’en servir, il suffit juste de lire toute la documentation sur comment installer les extensions, puis comment les activer. C’est tellement débile que c’est incroyable, pas vrai ? Le lien de la documentation officiel est ici.

      J’oubliais : si on veut utiliser un timestamp, en Django : il y est déjà. Même chose pour les autres types. Et si on veut vraiment une traduction avancée, on fait deux clics et une touche (je vous montrerai) en installant cela ici.

      Ah j’oubliais : le pire de tout : si cela a changé, surtout dites le moi dans les commentaires parce que je pense que c’est le summum de l’aberration : Doctrine ne connaît pas certaines formules comme YEAR(), COS() et SIN() (vital pour calculer des distances entre des villes par exemple, quelque chose de très courant aujourd’hui) et vous devez galérer à tout installer et préciser à la main, j’ai fait un gros article ici. J’insiste, je suis ouvert (autant que Symfony me le permet) : si cela a changé, surtout dites le moi dans les commentaires.

      Pour ceux qui commencent avec Symfony et qui n’ont jamais vraiment développé d’autres choses, vous allez toujours entendre le même discours, qui est quelque part logique : Symfony c’est génial, c’est super, c’est la réponse à la vie, l’univers, et au reste, il aurait dû s’appeler « Php – 42 » ou quelque chose comme ça (et si vous ne comprenez pas l’allusion c’est qu’on n’a ni le même background, ni le même humour). S’ils avaient vraiment pratiqué d’autres choses, il verraient qu’il y a plein d’autres trucs ailleurs, et ils verraient qu’à d’autres endroits il y a des choses mieux. Ceux qui n’ont pas d’expérience mais l’esprit ouvert me demandent où et je leur réponds. Ceux qui n’ont pas d’expérience et ont besoin de justifier leur existence diront « c’est un gros con il est dépassé il n’y comprend rien ». Je ne donne des cours que pour les premiers. Les autres je les laisse faire alt-tab en permanence entre Facebook et Symfony (et si vous saviez tout ce que je pense quand je parle ainsi…).

      Bref j’arrête de perdre du temps à expliquer que Symfony a de très bonnes idées et pratiques, mais que de tout vouloir mettre et faire en un seul endroit au final on a plus de problème qu’on n’en résout. Pour ceux qui ne me croient pas je leur laisse faire leur propre expérience…

  15. Kir

    Bonjour,

    J’avoue, je n’ai lu que le dernier post, et en travers…
    Je m’arrête sur « la pire abbération et la fonction year () ».
    Cette fonction n’est pas dans la norme et d’ailleurs n’existe pas en Oracle par exemple. Si tu utilises des fonctions spécifiques à certains systèmes, tu ne dois pas t’étonner que d’autres ne les connaissent pas. Doctrine de doit de rester sur la norme sinon on perd l’un de ses avantages : le multi base.
    Toi partout où tu auras implémenté ou utilisé ces fonctions spécifiques, tu vas devoir toutes te les retaper à coup de to_char ou autres si tu dois migrer….super.

    • Olivier Pons

      Bonjour Kir,

      Tu as raison, et ta remarque est bien justifiée, c’est pour cela que je valide en l’état ton commentaire !
      Maintenant, Symfony, c’est tellement loin de la simplicité et de l’efficacité de Django que bon, je ne me souviens même plus de ce que j’ai écrit ici !

      Bonne soirée !

      Olivier

Poster un commentaire

Vous devriez utiliser le HTML:
<a href="" title=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <cite> <code> <del datetime=""> <em> <i> <q cite=""> <s> <strike> <strong>