Je viens pour raler un peu. J'ai appris à coder en MVC sur php à partir de cakephp 2, puis 3.
Aujourd'hui, j'essaye de me mettre à symfony, parce que des que je parle de cakephp à un recruteur.. il me regarde comme si j'étais un témon de Jéhovah..

Et bordel.. qu'est ce que je le trouve naze ce framework !! alors dans le désordre :

  • Pas de documentation en Français.. pour un framework Français.

  • Le délire de coder dans des lignes de commentaires.. qui a eu cette idée ? (vous allez me dire qu'on est pas obligé de l'utiliser, mais la version xml ou php du même code est bien trop verbeux)

  • Pas de système de pagination intégré nativement.. sérieusement ?

  • La séparation entre entity, manager, et repository. Pourquoi faire simple quand on peut faire compliqué.

  • L'injection de dépendance dans les fonctions, qui fait des choses magiques, mais contre-intuitif.

  • L'ORM qui a l'air d'une usine à gaz.. j'essaye de retranscrire du code cakephp en symfony, ça me prend 3 fois plus de codes.

  • Le problème N+1 soulevé dans la formation.. je suis tombé de ma chaise en voyant le comportent natif de l'ORM à ce niveau là.

  • De manière générale, j'ai des fonctionnalités "basiques" sur cakephp, que je ne trouve nulle part dans symfony, exemple : je cherche à joindre une table à un parent, avec une clé étrangère (du genre parent_id), et un type (du genre article, commentaire, ou user), pour avoir une table enfant générique qui peut être liée à un parent, avec un id et un type. C'est utile, par exemple, pour créer un système de commentaire, qui sera lié à n'importe quelle table de la BDD.. et bien.. j'ai rien trouvé pour faire ça nativement.
    De même pour le "countercache" de cakephp qui permet de sauvegarder dans le parent, le nombre d'enfant, très pratique.

  • Devoir à chaque fois préciser quel fichier de vue on veut utiliser pour rendre une page.. C'est stupide. Pourquoi il ne va pas chercher automatiquement une vue qui porte le nom de la fonction ?

  • Dans cakephp, les controller héritent de Appcontroller, qui lui hérite de Controller. C'est très pratique pour définir un comportement de base à exécuter quelque soit l'action de n'importe quel Controller. Quel est l'équivalent ici ?

  • Le système de validation des données, avec des annotations dans l'entity.. ok super. et comment je fais pour avoir plusieurs système de validation pour un même champs en fonction du contexte ? Dans cakephp, j'ai souvent un validator pour le front, et un validator pour l'admin.

  • Existe-t-il un générateur de CRUD qui génère le code basique dans le controller (index, view, edit, delete) ?? je ne l'ai pas trouvé.

En bref, j'ai l'impression de regresser à tous les niveaux, sauf avec twig, qui est plutot sympa, et Encore qui permet de gérer webpack facilement.. mais bon, ça révolutionne pas ma vie non plus.

J'aimerai bien l'avis de dev qui sont dans le même cas de figure, qui ont utilisés plusieurs framework et qui pourront m'expliquer pourquoi j'ai tort (ou raison).

Et bonne année ;)

4 réponses


Salut, pas besoin de pousser un coup de gueule, c'est leur philosophie. Pour ma part, je suis passé de CakePHP à Laravel, c'est différent, mais je m'adapte (c'est le rôle d'un développeur, s'adapter).

Pas de documentation en Français.. pour un framework Français.

Comme la plupart des technos web, râle pas et apprend l'anglais, ça te servira tôt ou tard

Le délire de coder dans des lignes de commentaires.. qui a eu cette idée ? (vous allez me dire qu'on est pas obligé de l'utiliser, mais la version xml ou php du même code est bien trop verbeux)

Pourquoi tu râles ? C'est pas obligé. Java utilise ça, on appelle ça des annotations

Pas de système de pagination intégré nativement.. sérieusement ?

composer require knplabs/knp-paginator-bundle c'est pas la mort

La séparation entre entity, manager, et repository. Pourquoi faire simple quand on peut faire compliqué.

Ca tient en 2 mots DESIGN PATTERN

L'injection de dépendance dans les fonctions, qui fait des choses magiques, mais contre-intuitif.

T'es pas obligé de l'utiliser, moi je déteste ce genre d'injection, donc je l'utilise pas

L'ORM qui a l'air d'une usine à gaz.. j'essaye de retranscrire du code cakephp en symfony, ça me prend 3 fois plus de codes.

Ca tient en 2 mots DESIGN PATTERN

Devoir à chaque fois préciser quel fichier de vue on veut utiliser pour rendre une page.. C'est stupide. Pourquoi il ne va pas chercher automatiquement une vue qui porte le nom de la fonction ?

Comme ça, tu peux utiliser un fichier qui porte pas le même nom que ton action ;) ou utiliser le même fichier pour plusieurs actions

Ce que je retiens de ta critique, c'est que tu as été habitué à ce qu'on face tout pour toi, et on le voit à la fin de ton message (Encore qui permet de gérer webpack facilement) et que dès que tu sors de ton confort, tu es perdu. Il faut savoir s'adapter et pouvoir changer de techno facilement. C'est ça qui plait aux recruteurs ;)

Hello,

Pour te donner mon avis :

  • La doc n'est pas en français, car sinon, ce framework ne serait pas si populaire un peu partout. Et maintenir plusieurs langues c'est beaucoup de temps. L'anglais est devenu le language de référence dans notre domaine depuis bien longtemps. Même si ce n'est pas toujours simple...
  • Le système d'annotation est extrêmement efficace à l'usage, et en maintenance, c'est très pratique de retrouver l'info dans son contexte plutôt que dans un fichier de paramètres externe... Comme le dit @Balsakup, d'autres languages comme Java l'utilisent également.
  • Pour ce qui est de l'ORM, de l'injection de dépendance, des vues, etc, utiliser des design pattern est un gage de maintenabilité et de robustesse. C'est vrai qu'il faut un certain niveau pour les utiliser, mais c'est une bonne pratique. C'est mieux que de coder un plat de spaghetti inmaintenable par la suite et qui aura du mal à évoluer...
    De plus, la couche ORM permet de dissocier complètement le code de la base de données utilisée. D'ailleurs l'ORM Doctrine est simplement intégré à Symfony, mais c'est un projet open source bien à part, qui n'a rien à voir avec Symfony...
  • Pour les controllers, il est possible d'étendre un AbstractController qui amène pas mal de Helpers bien pratiques, tout en laissant le code indépendant. Bref le meilleur des 2 mondes.
  • Grâce aux groupes de contraintes, tu peux valider tes données dans plusieurs contextes différents (voir https://symfony.com/doc/current/validation/groups.html).
  • Tu peux générer un CRUD grace à une ligne de commande :
    ./bin/console make:crud

    Perso je ne l'utilise pas, le code généré n'est pas super top à mon sens (trop de redondance, pas de form handler...)

Ce qu'on peut reprocher à Symfony, c'est sa courbe d'apprentissage un peu élevée, et du bagage technique qu'il faut en pré-requis. Un dev java aura certainement moins de mal à s'y mettre. C'est aussi du à l'utilisation systématique de design pattern ainsi qu'au suivi des normes PSR (qui sont également une bonne pratique).
C'est le prix à payer pour un dev maintenable et évolutif.

Symfony 4 apporte plus de simplicité et de légèreté avec Flex. Créer un système d'authentification devient également hyper simple.

Le gros plus de Symfony c'est son énorme communauté et ses bundles (add-ons).
Je te conseille de regarder certains bundle sympa comme le maker bundle (à partir de Symfony 3.4), Liip Imagine (gestion des images), VichUploader (upload de fichiers dans un formulaire), Doctrine extensions (gestion d'arbres intervallaires, automatisation de certains champ de DB...), easyadmin (générateur d'admin super pratique), KnpPaginator (pagination), KnpGaufrette (gestion abstraite de fichiers quelque soit sa source), etc...

Bref, il faut se pencher un peu plus en profondeur sur tout ça pour en mesurer tout l'intérêt...

Flitflit
Auteur

Merci pour vos réponses ;)

Ce n'était pas un topic pour raler, mais pour essayer de comprendre la popularité de symfony.

Pour répondre un peu à vos remarques :

Je sais bien que l'anglais est la langue de référence.. mais quand je vois que le cookbook de cakephp est traduit en 7 langues, j'imaginais en arrivant sur symfony, avec sa réputation, qu'il serait traduit en ch'ti et en mandarin traditionnel.. bah non, apprends l'anglais technique et ferme la.

J'ai passé mes journées sur la doc depuis mon topic, et je commence (un peu) à comprendre ce framework, et le gros point faible reste doctrine et les entity selon moi.. faire un simple système de tag avec une relation ManyToMany relève de l'exploit.

Pour les annotations, je ne suis pas convaincu par vos arguments. ça a un coté "hack" du code de base PHP. Tout le framework d'ailleurs : xml, yaml, annotations, twig.. en faite les mecs ont créés un framework sur PHP mais on dirait qu'ils font tout pour pas utiliser PHP.
Quand je vois qu'en nodeJs on fait tout pour utiliser du full JS pour pas avoir à jongler avec différent language, sur symfony on a jusqu'à 6 langages différentes (si on inclut du javascript en front)

Mais j'admets volontier que c'était un topic d'un dev frustré, car je dois passer sur symfony parce que la communauté a adopté ce framework, parce qu'il a réussi à s'imposer je ne sais pas comment, et que je vois ce que je perds avec, mais pas ce que je gagne..

Bonjour Flitflit.

Je comprends ce que tu dis pas rapport a la documentation non traduite, moi même je ne suis pas du tout alaise en anglais, vraiment pas. Mais il est vraiment beaucoup plus facile de trouver des réponses a des problèmes que l'on rencontre en anglais sans compter que certaines documentations sont très mal traduite en français. Je préfère ça que les documentations en chinois.

Tu pense que doctrine et les entités sont un point faible, mais si tu veux faire une application ou site c'est extrêmement puissant que ça soit pour des petits ou des gros projets. Regarde les commands pour générer les entités et tu n'auras quasiment plus besoin de regarder tes entités.

Je pense que tu n'as pas compris le but d'un framework comme symfony. Le but n'est pas d'apporter de la souplesse, mais un cadre rigide et ouvert permettant de dev n'importe quoi, mais avec son cadre rigide permet qu’un projet dev puisse être récupéré et le code ré utiliser et je ne parle pas de tout les testes applicatif que cela permet. (Sans compter les testes de charges, etc.)
Bien sûr pour cela ça demande de l'apprentissage, car il y a des choses plus ou moins complexes qui sont utilisées pour créer ce cadre.
Pour la partie découpage, tu peux très bien tout mettre en php si tu ne veux pas de Yaml ou de twig. Ils les ont mis en place pour des raisons de lisibilité du code et de découpage.

Pour l'exemple du nodejs il est vrai que tu codes que en js et si tu utilises un framework comme express ça te donne un cadre plus ou moins rigide. Mais personnellement si on me propose de récupérer un projet fulljs, je refuserais, car js vu qu'il n'y a pas de cadre très rigide, bien souvent les projets sont codés a l'arrache et lorsque tu vois du code js bien fait, il a souvent des transpiller. Et franchement je n’aime pas l'idée de devoir apprendre un autre langage juste pour coder proprement.