PRINCIPALES DIFFÉRENCES ENTRE LARAVEL ET SYMFONY

À l'ère du grand nombre de frameworks PHP, les développeurs PHP sont souvent confrontés à la question suivante : quel framework utiliser pour leurs projets ?

Beaucoup sont déjà indécis, ayant trouvé ce qui leur convient le mieux, et pour certains il est difficile de déterminer la réponse.

Voyons et comparons certaines caractéristiques de frameworks aussi populaires que Symfony et Laravel.

 

Installation du Frameworks

Les fichiers de base des frameworks PHP modernes peuvent être installés à l'aide du gestionnaire de paquets Composer.

Ainsi, pour Laravel, cela peut être fait avec la commande composer create-project --prefer-dist laravel/laravel nom_du_projet pour Symfony composer create-project symfony/website-skeleton nom_du_projet, où nom_du_projet est le nom du projet et en même temps le nom du répertoire créé où composer placera les fichiers du framework.

En même temps, les deux systèmes ont maintenant leur propre installateur, laravel nouveau nom de projet et symfony nouveau nom de projet, et les installateurs eux-mêmes peuvent être installés en exécutant une seule ligne : composer global require laravel/installer et wget https://get.symfony.com/cli/installer -O - | bash respectivement.

Vous pouvez ainsi constater que le processus d'installation de la fonctionnalité minimale est réduit au minimum et prend très peu de temps.

 

Mise en place

Les deux frameworks prennent désormais en charge un fichier de configuration .env qui stocke des paires clé-valeur, mais Symfony prend également en charge les fichiers yaml pour la configuration du routage, des services et autres.

Le format yaml est très utile et vous permet de spécifier les valeurs de configuration d'une manière qui ressemble à un tableau multidimensionnel.

 

Routage

Chaque framework a sa propre façon de spécifier les routes d'application et de les lier aux contrôleurs. Ainsi, pour spécifier dans Laravel que la route "/test" doit être traitée par la méthode TestController, vous devez spécifier ce qui suit dans le fichier de routage routes/api.php : Route::get('/test', 'TestController@test')->name('test_name') ; Pour Symfony, on peut faire de même avec les fichiers yaml responsables du routage ou, plus commodément, avec les annotations .

namespace App\Controller;

use Symfony\Component\HttpFoundation\Response;
use Symfony\Component\Routing\Annotation\Route;

class TestController {

    /**
     * @Route("/test", name="test_name")
     */
    public function test() {
         return new Response('Some test text');
    }
}

 

 

 

L'utilisation de contrôleurs présente un grand nombre d'avantages. Ainsi, dans le chemin d'accès "/test", vous pouvez spécifier des paramètres dynamiques, par exemple "/test/{id}". Maintenant vous devez spécifier le paramètre $id dans la signature du contrôleur, et sa valeur sera tirée du chemin. Vous pouvez également formater les paramètres dynamiques à l'aide d'expressions régulières. Ainsi, par exemple, $id est uniquement un nombre entier. En outre, chaque cadre dispose d'une fonctionnalité permettant de combiner les routes en groupes et de leur attribuer des préfixes, d'attribuer des méthodes HTTP par lesquelles ces routes seront disponibles et de fournir un support pratique pour les paramètres GET et POST.

 

Migrations et ORM

Les deux systèmes offrent un ensemble utile de commandes de console pour les migrations de projets, mais la principale différence entre Laravel et Symfony réside peut-être dans leur mode de fonctionnement. Dans Laravel, nous devons créer des migrations par nous-mêmes, et nous devons aussi garder la structure de notre base de données et les classes PHP synchronisées.

Ainsi, par exemple, le code de migration ressemblerait à ceci

Schema::create('tests', function (Blueprint $table) {
$table->bigIncrements('id') ;
}) ;


et la classe Test ressemblera à ceci

namespace App;

use Illuminate\Database\Eloquent\Model;

class Test extends Model
{
    protected $table = 'tests';
}


Comme vous pouvez le constater, tous les modèles de Laravel héritent de la classe Model.
Dans Symfony, en revanche, vous travaillez avec les migrations par le biais de l'ORM Doctrine. Ici, nous ne pouvons travailler qu'avec des classes et des annotations PHP.
Ainsi, un exemple de code pour la classe Test ressemblerait à ceci

 

namespace App\Entity;

use Doctrine\ORM\Mapping as ORM;

/**
 * @ORM\Entity()
 */
class Test
{
    /**
     * @ORM\Id
     * @ORM\GeneratedValue
     * @ORM\Column(type="integer")
     */
    private $id;
}

 


Après avoir créé l'entité Test, nous pouvons commencer à créer une migration où Symfony crée lui-même le code SQL exécutable pour créer la table des tests avec la colonne id. De plus, nous n'avons pas besoin de maintenir la structure de la base de données et les classes PHP aussi soigneusement que possible, car lors de la création des migrations, le framework compare la structure actuelle de la base de données avec celle attendue sur la base des classes PHP actuelles et génère tout le SQL nécessaire.

Il est intéressant de noter que les deux frameworks fournissent des ORM pour l'analyse des bases de données. Dans Laravel, c'est Eloquent qui s'en charge. Ainsi, par exemple, le code ci-dessous permet d'obtenir une collection d'objets de la classe Test :

$tests = App\Test::where('id', '<', 100)
   ->orderBy('id', 'desc')
               ->take(10)
               ->get();


Dans Symfony, ce type de code fréquemment utilisé est déplacé vers des classes spéciales de dépôt, tandis que le corps de la méthode elle-même ressemble à ceci

$tests = $this->createQueryBuilder('t')
            ->where('t.id < :id')
            ->setParameter('id', 100)
            ->orderBy('t.id', 'DESC')
            ->setMaxResults(10)
            ->getQuery()
            ->execute();


Dans ce cas, il retournera un tableau d'objets de la classe Test, et l'ORM de Doctrine s'en chargera.
Eloquent et Doctrine mettent tous deux en œuvre le modèle de conception Fluent Interface, comme vous pouvez le voir d'après les noms des méthodes where, orderBy et autres. 

Si vous êtes familier avec l'un des moteurs de création de modèles, vous comprendrez l'autre sans trop de difficultés. En ce qui concerne le front-end, Laravel prend également en charge Vue.js, ce qui ouvre des possibilités supplémentaires, mais dans le web d'aujourd'hui, il n'est pas impossible d'utiliser n'importe quel framework back-end PHP en combinaison avec un framework front-end JavaScript tel que React, Angular ou Vue.js. En conclusion, parmi les deux grands frameworks, Laravel et Symfony, vous ne pouvez pas choisir le meilleur, mais seulement celui qui répond le mieux à vos besoins spécifiques. Bien qu'elles mettent en œuvre des stratégies différentes pour créer l'application web résultante, aucune des deux implémentations ne peut être qualifiée de mauvaise. Les deux frameworks vous permettent d'étendre considérablement les fonctionnalités de base en fonction de vos besoins, et le grand nombre de paquets installés avec composer ne fait qu'y contribuer. Laravel et Symfony peuvent tous deux être utilisés aussi bien pour les petits sites que pour les sites d'entreprise, notamment en raison des systèmes de mise en cache intégrés et des hautes performances. Chacun d'entre eux est potentiellement extensible, de sorte qu'une fois que vous avez choisi un cadre pour un nouveau projet, c'est à vous de décider de son extensibilité.

 


PHP, Symfony, Le code parfait


Parfois, en dépit de tous les défauts, la technologie explose. Tous ces problèmes sont vus, grondés, surpris, mais rien ne peut être fait. Il a déjà été tiré, donc vous devez l'utiliser, bien sûr, de manière inattendue, mais une fois par an et un bâton tire. Bien que l'émergence rapide des nouvelles technologies dans le développement web ressemble davantage au travail d'une mitrailleuse en bois à plusieurs canons, crachant des excréments. En passant de la métaphore à la spécificité, je dirais qu'à mon avis, le framework PHP Symfony est un représentant vivant de ces technologies. Et c'est des problèmes de ce cadre que je voudrais parler.

Parmi ceux qui utilisent Symfony, il y a pas mal de gens qui l'aiment sincèrement. Mais il y a aussi beaucoup de gens qui aiment sincèrement cette activité et qui gagnent pourtant de l'argent avec elle. Ce que j'ai écrit ci-dessous n'est donc rien d'autre qu'une psychothérapie pour les seconds, et une référence pratique pour les fans de Yii, par exemple, pour troller les premiers.

Introduction

Lorsque j'ai commencé à travailler avec ce cadre pendant 4 ans, je pensais qu'il était trop compliqué. La communauté m'a expliqué que j'étais un nerd qui n'avait pas essayé beaucoup d'autres frameworks web pour en tirer des conclusions. Cette explication m'a doublé. Il y a 3 ans, j'ai eu la chance d'être associé à un fan de Symfony, qui voulait tout faire bien et selon l'idéologie, ce qui nous a fait échouer lamentablement dans le respect de nos délais. Un de mes collègues m'a expliqué qu'il ne fallait pas faire du code à la con. Cette explication relevait du domaine de l'idéologie et je préférais ne pas polémiquer. Il y a 2 ans, j'ai construit moi-même plusieurs projets types en utilisant le moins de composants Symfony possible et j'ai été agréablement surpris. La communauté m'a dit que j'étais de faible intelligence et que je n'étais pas très doué pour manipuler des abstractions complexes. Ce n'est pas que je sois satisfait de cette explication, mais elle explique au moins ce qui se passe. Il y a un an, j'ai reçu un projet dont le propriétaire était mécontent des coûts de maintenance élevés et de la faible vitesse de développement. Le projet a été écrit par des gars sérieux, tout a été fait dans les règles, le code était parfait. Tout a été utilisé : les filtres assetica, toutes les fonctionnalités des formulaires, les événements ont été activement utilisés, les bundles les plus populaires ont été utilisés là où il y avait la moindre opportunité de ne pas écrire son propre code, le code était donc un exemple rare, que l'on voit rarement en Open Source. J'ai mis cela sur le compte du fait que les "stars" se sont lassées de fournir un soutien de routine et ont commencé à travailler sans enthousiasme. Eh bien, que pouvais-je penser d'autre, si les paquets de cadres proliféraient, et que le cadre lui-même non seulement recevait une subvention, mais était considéré comme un modèle de perfection partout ?

Finalement, il y a un mois, j'ai été contraint de quitter ce projet, le confiant à un autre programmeur. Lorsque j'ai commencé à chercher un remplaçant, j'ai été confronté au fait que toutes les questions relatives à Symfony auxquelles je pouvais penser pour l'entretien d'embauche s'enlisaient dans des informations de base, ce qui, compte tenu de leur abondance, n'était pas surprenant mais inconfortable. La stratégie consistant à rechercher "juste un programmeur sain d'esprit" aurait été un échec - j'avais besoin de quelqu'un qui se serait immédiatement lancé dans le projet, sans perdre son temps à se battre avec les subtilités du cadre, qui avait déjà un don pour cela. De plus, le projet lui-même était un simple CRUD, bien que volumineux. J'ai donc dressé une liste approximative des éléments clés que chaque programmeur doit rencontrer, afin de vérifier si le candidat les a effectivement rencontrés avant de venir me voir. Mais cette approche m'a fait réfléchir.

De plusieurs entretiens, je suis arrivé à plusieurs conclusions. Tout d'abord, presque personne ne connaît vraiment Symfony, à l'exception des personnes qui non seulement travaillent avec mais, désolé de le dire, pètent dedans. Deuxièmement, même ceux qui sont familiers avec un grand nombre de composants Symfony se plaignent de sa complexité et ne l'utilisent pas. Tout cela a fini par me convaincre qu'il y a quelque chose qui ne va pas dans ce framework.

Un peu d'histoire

Symfony a maintenant presque 5 ans mais c'est ce qu'on appelle Symfony 2. La deuxième branche est presque 100% compatible avec la première (sauf pour le double à la fin). Il s'agit d'un cadre différent et le premier est déjà oublié par tout le monde. L'histoire concerne le cadre Symfony 2, les premiers commits au dépôt Symfony sur github ont été faits en janvier 2010.

Dès le début, le framework a été positionné comme une collection de toutes les dernières, meilleures et plus grandes innovations dans le développement web PHP. Maintenant, c'est une autoroute à quatre voies. Le corporatisme du cadre était tel que le créateur proposait des cours de formation avec certification alors que le cadre était encore loin d'être prêt pour une utilisation industrielle. Ou peut-être que c'était juste un moyen de le monétiser, et si c'est le cas, c'était un succès. L'existence même de ces cours laissait déjà penser que le cadre n'était pas pour les âmes sensibles et qu'il était en général destiné à impressionner les personnes sérieuses, habituées à voir une forte corrélation entre le certificat et l'aptitude professionnelle de son détenteur. Et il est vrai qu'il reprenait beaucoup de choses du monde douillet de Java : l'injection de dépendances, où même la mère native pouvait être déclarée un service serait une ligne blanche dans la config, l'ORM était comparable en complexité à Hibernate, et les annotations étaient plus que des annotations, et comme touche finale, la structure ultra-modulaire, sauvagement fragmentée en fichiers et essayant d'extraire toutes les caractéristiques OOP de PHP.

Tout cela était tellement conforme à l'esprit de la programmation de haut niveau qu'un jour le créateur du framework a reçu une subvention de 7 millions de dollars pour développer son idée. Un cadre sérieux pour des tâches sérieuses a reçu non seulement des arguments au sein de l'idéologie existante du code parfait, mais aussi un argument compréhensible par tous les programmeurs, même ceux qui ne sont pas liés au code parfait, et, de plus, pas liés à la programmation.

Au début, le framework était vanté et, malgré sa maladresse infernale en 2011, tout le monde ne parlait que de son excellence. De manière caractéristique, de nombreuses personnes, dont moi, sont tombées dans le panneau et ont décidé de choisir ce cadre comme moyen d'orientation professionnelle. Certains se sont tus, d'autres ont craché dessus, mais grâce à la démagogie et au remplacement actif des termes (les composants de symphonie sont utilisés dans de nombreux endroits == symphonie est utilisée dans de nombreux endroits), les problèmes ont été réduits au silence dans une large mesure et la popularité de Framework a augmenté. Et une fois la subvention accordée, tous les opposants pouvaient être réduits au silence. Le cercle de l'auto-soufflage était fermé.

Brièvement sur les points principaux

Le cadre est trop compliqué, et ce sans raison apparente. Et tout est cloué sur place mentalement. Dans un effort pour rendre l'architecture du cadre aussi flexible que possible, une tonne d'abstractions ont été construites, ce qui a nécessité du temps pour faire fonctionner du code utile dans ces abstractions. Ainsi, tout est comme Java, mais seulement en PHP.

Il n'y a aucun moyen de s'en débarrasser - un écart par rapport à l'idéologie standard est fortement désapprouvé par la communauté. Vous ne pouvez pas simplement rejeter l'utilisation d'un composant qui est devenu transversal au projet. Cela a un coût énorme en termes de réputation pour le pauvre type qui suggère que vous ne devriez pas utiliser l'ACL ou les formulaires standard, par exemple. Si vous décidez de laisser tomber Doctrine de votre projet, vous aurez une longue explication fatale à tous ceux que vous rencontrerez par la suite pour expliquer pourquoi vous l'avez fait, accompagnée d'un secouage de tête plein de reproches. Les composants Symfony sont excellents en soi (ce qui donne à de nombreux développeurs tiers l'impression que l'ensemble du framework est aussi bon), mais lorsqu'ils sont réunis, les choses se gâtent.

Bien que beaucoup de temps se soit écoulé depuis la création du PHP et que de nombreux stéréotypes aient perdu leur pertinence, il arrive encore très souvent que des déchets subsistent dans le domaine du développement web. Dans les petits projets, personne n'écrit de tests, personne ne travaille sur une bonne architecture, personne ne réfléchit à la manière de la maintenir. Bien sûr, dans les projets de moyenne et grande envergure, tout cela commence à se produire après que le projet a "survécu". C'est mauvais, mais c'est un mode de vie. Selon mon sentiment, Dieu, seulement 20-30% des développeurs suivent ce qu'ils écrivent sur Habra sur la façon de développer correctement des programmes. Dans d'autres cas, il s'agit d'un déchet où un code parfait n'est bon qu'en tant qu'épitaphe sur la tombe d'un projet. Dans ce cas, utiliser Symfony selon n'importe quelle norme de qualité, ce n'est pas seulement jeter des perles aux cochons, c'est inonder le cochon de tant de perles qu'il s'essouffle et meurt en cherchant de l'air.

Symfony vous donne une courbe d'apprentissage colossalement alambiquée, en plus de laquelle vous n'atteindrez pas une efficacité de développement plus élevée que dans d'autres cadres, mais apprendrez plutôt à lutter avec Symfony lui-même. Parfois, c'est le genre de cadre dans lequel il est plus facile de tout réécrire soi-même que de suivre ses lignes directrices. Je pensais que j'étais un idiot incapable de comprendre Symfony, jusqu'à ce que je tombe sur le code de quelqu'un qui était un conférencier de Symfony et maintenait son propre fork du framework. Ce code a implémenté son propre mécanisme ACL. Dans les commentaires du code, il dit avoir écrit son propre ACL en raison de la complexité de l'ACL standard de Symfony. Peut-être est-il lui aussi un idiot, on ne sait jamais, mais il faut y réfléchir.

Développeur Symfony uniquement

La complexité du cadre est telle que je trouve que si je ne travaille pas activement sur un projet dans Symfony pendant quelques semaines, je dois me remettre en question non seulement pour le projet, mais aussi pour le cadre. Peut-être que ma mémoire est défaillante, mais est-il possible pour un lecteur plus observateur qui croit que cette difficulté n'existe pas de s'en souvenir immédiatement et d'écrire sans avoir à googler ou copier le mode d'emploi ?

-faire de l'héritage de table dans la doctrine, une action typique pour plusieurs groupes d'utilisateurs
-ajouter un nouveau rôle à l'ACL standard
-ajouter une aide à Twig
-ajouter une annotation pour VARCHAR et TEXT au modèle
-ajouter un référentiel
-ajouter un nouveau groupe de validation à un formulaire
-ajouter un transformateur à un formulaire
-déclarer quelque chose comme un service, éventuellement avec plusieurs arguments, et écrire une usine pour ce service
-mettre en œuvre le chargement d'un fichier lié à l'entité
-ajouter le support des fonctions agrégées SQL à la doctrine
-écrire une commande de console


Si vous vous souvenez de tout cela par cœur, félicitations - vous avez une mémoire phénoménale. Malheureusement, je ne peux pas me souvenir de tout cela par cœur car je dois généralement mettre en œuvre chacune de ces choses pas plus d'une fois par semaine. C'est pourquoi Symfony a été la première technologie pour laquelle j'ai eu un livre de référence, que je mets à jour régulièrement. Le programmeur moyen comme moi a donc deux choix. Envoyez un grand nombre de fonctionnalités Symfony en enfer, et rougissez chaque fois que quelqu'un voit votre code. Vous pouvez aussi vous procurer un ouvrage de référence, car tous les développeurs moyens ne doivent pas avoir la patience de chercher sur Google tout le temps.

Il existe aussi une troisième voie spéciale, de langue maternelle russe, c'est que vous allez travailler dans le web-studio de bas niveau, qui rivete les sites au modèle, ce qui signifie que vous serez 10 fois par jour, à répéter les mêmes quelques opérations, ce qui leur permettra de se souvenir. Cela vous donnera l'illusion que vous connaissez déjà Symfony. Mais si vous êtes assez curieux, vous l'aurez. Mais pourquoi ?

Malheureusement, je n'ai pas trouvé le moyen de répondre à toutes les exigences d'un programmeur Symfony moderne sans avoir Symfony dans la tête. Si vous, cher lecteur, en avez trouvé une, et qu'il ne s'agit pas d'un gain à la loterie génétique, alors partagez-la dans les commentaires.

Concepteur

Quand j'ai vu que Drupal, depuis la version 8, a beaucoup de points communs avec Symfony, ma surprise a été sans fin. Parce que les deux produits sont essentiellement des créateurs de sites web, malgré le fait que dans un cas nous avons un CMS et dans l'autre un cadre général. Le concept de constructeur pour la plupart des sites web actuels est peut-être celui qui permettra de gagner du temps, d'améliorer la sécurité en utilisant de multiples composants testés. Il y a encore toutes sortes de fioritures qui sont très jolies, mais qui ne sont pas disponibles pour le vieux web-macaque qui ne connaît pas les mots du design à mettre en œuvre tout seul. Et les clients adorent ça. Les volants, pas les vieux webmacs.

Mais il existe un certain équilibre entre le temps que vous passerez à compléter le bloc prêt à l'emploi pour le faire fonctionner dans votre projet et le temps que vous passerez à écrire cette fonctionnalité vous-même. Dans le cas de Symfony, ce choix est ambigu - la complexité du cadre, la complexité de l'architecture des bundles, la courbure des bundles qui se brisent parfois lors de mises à jour mineures - tout cela fait de l'utilisation d'unités pré-construites un choix moins évident. Même si une offre groupée standard vous fera gagner de nombreuses heures à l'avenir, si vous ne mettez pas en place de nouvelles fonctionnalités aujourd'hui, il n'y aura peut-être pas d'avenir. Et il se peut que vous ne le fassiez pas, si vous voulez jouer avec le paquet - ils ne fonctionnent pas tous à partir de zéro. Il m'est même arrivé, après des heures de souffrance, de jeter un wrapper de bundle autour d'une bibliothèque populaire et de finir par utiliser mon propre wrapper ou un accès direct à la bibliothèque. Symfony est populaire maintenant, ce qui signifie beaucoup d'auto-propagandistes, désireux d'obtenir une centaine ou deux étoiles sur le githab. Malheureusement, après les premières étoiles, ces programmeurs perdent leur enthousiasme et vous pouvez effectuer vous-même les corrections de bogues.

L'idée d'un grand constructeur de sites web est souvent critiquée car cette approche est difficile à maintenir et à trouver des personnes capables de la maintenir. Vous ne pouvez pas trouver une personne sous les technologies que vous avez. Dans le monde Perl, c'est même l'un des problèmes les plus courants - il ne reste que le nom du framework web, on peut tout cacher sous le capot. Et cela conduit à trouver "juste un bon programmeur" et à lui donner le temps de s'investir dans le projet. Pour PHP, où une très grande partie des projets sont de petite taille, où les budgets sont réduits et où le marché du travail regorge de personnel médiocre, le soutien à un constructeur de sites web en général soulève de sérieuses questions.

Domaine de niche ?

Symfony, tel qu'il est actuellement, se trouve dans une niche obscure. Il a été écrit plus haut qu'il est mieux adapté au marquage en masse des sites basés sur des frameworks basés sur lui. Mais il s'agit de l'essentiel du développement web, surtout si l'on considère que les programmeurs qualifiés se contentent de cet essentiel et travaillent dur pendant 10 heures d'affilée.

Il existe un livre assez formel et ennuyeux à ce sujet, qui couvre plus ou moins tous les détails techniques. Il existe également un cours sur ce sujet. Est-il destiné aux grands projets sérieux ? Ok, disons. Nous disposons de toutes les fioritures architecturales nécessaires aux grands projets. Et la fragmentation, adaptée aux tests, et les événements dans le cadre principal, et DI, et les fichiers de configuration contrôlés par la divinité corporative Xamael, et des choses comme ça.

En y regardant de plus près, tout cela n'est rien d'autre qu'une mise en œuvre de nombreux modèles qui se génèrent d'eux-mêmes dans tout grand projet. Mais seulement si vous en avez besoin. Symfony dit explicitement qu'ils sont nécessaires. Et exactement comme implémenté dans Symfony. Bien que l'utilisation d'un ORM tel que Doctrine dans les projets d'entreprise soit extrêmement discutable - les longues requêtes DQL sur des dizaines de tables ne sont pas quelque chose que même les pires cauchemars peuvent imaginer. Une ACL qui est liée à LDAP et à je ne sais quoi d'autre, et qui doit être écrite presque à partir de zéro en essayant de s'adapter à l'ACL standard de Symfony. Avec d'autres architectures, il est étonnant que le composant permettant de vider des structures de données récursives (ce qui représente à peu près tout ce que vous voudrez vider) soit apparu dans la v2.6, après la publication de la première branche LTS. Il a fallu environ 4 ans pour qu'une fonctionnalité aussi élémentaire apparaisse dans le cadre.

Pour les petits projets ponctuels, Symfony est une bonne solution en raison du grand nombre de packs disponibles. Mais elle n'aboutit pas en raison de la complexité de l'apprentissage et... des problèmes causés par le cadre lui-même, qui prennent beaucoup de temps. D'autre part, il est facile de construire votre propre framework basé sur Symfony, adapté à votre travail spécifique. D'autre part, d'aussi loin que je me souvienne, les studios web ont toujours construit des frameworks basés sur n'importe quoi pour leurs propres sites web typiques. La difficulté de remplacer un programmeur est la même que vous utilisiez un fork Symfony ou un projet écrit par vous-même.

Pour un site web moderne, Symfony est bon car il est coincé au même niveau que le Web 2.00, ou plutôt ses premières révisions. Symfony Forms est excellent tant que vous n'avez pas à créer des formulaires semi-dynamiques ou dynamiques. Pour des trucs sympas, les formulaires Symfony sont parfaits, pour du CRUD avec quelques champs dynamiques, ils sont corrects, pour une logique côté client un peu complexe, vous pourriez vouloir revoir la conception d'un formulaire. La validation et la sauvegarde des données doivent également être repensées. Les formulaires sont donc une excellente chose, mais la transition d'un front-end simple à un front-end complexe n'est pas bien pensée. Il en va de même pour Assetic. Mais à tous les autres égards, Symfony promeut l'approche la plus avancée (ou stéréotype correct ?) en tout.

Pour les projets d'entreprise, Symfony est bon parce qu'il dispose de LTS et d'un support officiel, de cours de certification, mais il est mauvais parce que... eh bien, les logiciels d'entreprise s'avèrent toujours être monstrueux et difficiles à maintenir, quel que soit le cadre et le langage.

Problème d'isolation des composants

Même pour des modifications mineures, vous devez manipuler un grand nombre de fichiers. Par exemple, si vous ajoutez un champ à un formulaire, vous devez :

ajouter le champ au FormType
ajouter un rendu au modèle
si vous avez besoin de dépendances pour le nouveau champ (p.ex. réception de données externes pour la listbox), vous devez faire des changements dans services.yml, constructeur de formtape
si votre champ est lié à un champ du modèle mais ne peut pas être enregistré directement dans la base de données, vous devez modifier le moteur de rendu du formulaire.
si le champ est un fichier, vous devrez peut-être modifier le code du contrôleur, si vous ne voulez pas paralyser le modèle par une procédure d'enregistrement de fichier.
si vous avez des règles de validation dans le modèle (et dans 90% des projets, elles sont soit là, soit dans un yml séparé, mais pas dans le formtype), vous devez ajouter des annotations au modèle.
Le plus souvent, vous allez soit consulter le manuel de référence, soit copier les fichiers voisins.

Isoler les composants dans des fichiers et spécifier les dépendances de certains composants sur d'autres devient également un casse-tête au fil du temps. Vous ne pouvez pas simplement tirer le cadre de base via global, c'est faux ! Au lieu de cela, lorsque vous avez besoin de faire quelque chose de complexe mais toujours lié à cette Entité à l'intérieur, vous pouvez soit faire un passage des dépendances nécessaires à l'Entité, soit remanier toute la chaîne d'appel vers le haut, en vous assurant que les bonnes actions se produisent en même temps que la sauvegarde de l'Entité.

Dans les deux cas, cela est délicat et demande beaucoup de concentration - vous devez corriger le constructeur d'Entity ou son référentiel, en vous assurant que les bonnes dépendances sont transmises. Ensuite, faites des changements dans le fichier services.yml. Cela semble facile, mais même avec un IDE, cela prend du temps. La refactorisation avec des actions en amont qui nécessitent des dépendances est également difficile, ce qui est compréhensible. En fait, vous abandonnez le processus d'écriture de la logique métier pour vous plonger dans le processus d'adaptation au cadre. C'est à peu près comme être distrait par un appel téléphonique pendant qu'on écrit du code.

Pour les composants, une isolation maximale est une bonne chose. Pour la logique métier, je pense que cela entraîne une complexité inutile. Du moins la façon dont Symfony le présente.

Communauté

Dès que vous proclamez que quelque chose est le meilleur et que vous en faites activement la promotion, vous êtes presque assuré d'avoir un public qui veut rejoindre ce nouveau et meilleur. Ce public excusera tous les défauts et les lacunes de la technologie et vous, les dissidents... ne le ferez pas. Symfony implique implicitement (ou explicitement ?) les solutions les plus avancées, les approches les plus correctes, ce qui signifie implicitement que si vous n'êtes pas avec Symfony, vous appartenez à un collège - et votre destin est de vendre des sites Joomla. Le bon vieux "celui qui n'est pas avec nous est un imbécile".

Bon, disons que vous vous êtes adapté à un tel arrangement, et que vous avez appris à adopter le bon visage lorsque vous discutez de ce cadre. Vous êtes maintenant confronté à un autre problème : les solutions de pointe sont souvent grossières, elles sont souvent rejetées après quelques mois d'activité sur le githab. Mais vous serez conseillé à leur sujet, notamment par les auteurs eux-mêmes. Vous hériterez de paquets qui ne fonctionneront pas pour la 2.3 ou la 2.7, et pour lesquels vous devrez chercher les correctifs dans de nombreuses bifurcations. Et la qualité, la qualité... L'exactitude verbale s'avère parfois être une conformité aux RPS et un bon réglage des IDE. De ce fait, des tonnes de texte passe-partout donnent une fausse impression de qualité normale du code. La communauté Symfony est presque un exemple parfait illustrant le problème du fou de science - les connaissances sont superficielles, beaucoup de gens ne comprennent pas vraiment comment les choses fonctionnent, mais ils ont la démagogie pour justifier tous les problèmes et une arrogance inébranlable.

Le plus triste est qu'en règle générale, ces personnes ne connaissent pas parfaitement l'ensemble du cadre, mais connaissent souvent certaines de ses parties séparées, béquilles et autres astuces de chèvre. Par conséquent, lorsque quelqu'un ne sait pas ce qu'il sait, il refuse à chaque fois de remarquer la complexité du cadre et la grande quantité d'informations de base qu'il est impossible de garder dans sa tête. Ils vivent dans un cercle étroit de tâches où toutes les solutions de contournement ont déjà été trouvées, et ils ne se soucient pas des autres parties du cadre.

La communauté est le principal et unique catalyseur de tout le chaos de Symfony. Sans lui, nous aurions pu mettre au rebut Assetic, Forms, Doctrine et Good Practices et utiliser Symfony comme un micro-cadre normal dès le départ.


C'est vraiment si grave ?

Symfony n'est pas beaucoup plus mauvais qu'un autre framework, mais l'idéologie et les règles tacites qui accompagnent le framework le rendent inefficace à utiliser. En passant en revue ce qui peut et ne peut pas être fait avec ce cadre, il est possible de le manipuler aisément, malgré sa complexité. Dans le cadre de cette politique, une révision du Symfony Book afin qu'il réponde à des questions techniques spécifiques plutôt que d'enseigner un style de programmation approprié serait utile.

En raison de la complexité de Symfony, il y a un bon côté, non pas pour le client mais pour le programmeur, il paie un peu plus que les autres frameworks. Encore plus ! Vous pouvez créer dans ce cadre une architecture fantaisiste que personne d'autre ne peut comprendre, mais qui est techniquement parfaite. Cela rendra plus difficile la recherche de votre remplaçant. Et si vous prenez quelques semaines pour construire votre propre framework autour de Symfony, vous aurez beaucoup de plaisir à travailler en indépendant.

En conclusion

Je n'ai volontairement pas fourni d'illustrations de problèmes spécifiques tels que l'implémentation de fonctions agrégées dans Doctrine, la lenteur d'Assetic, les limitations de la modélisation des formulaires, les exemples passe-partout, etc. Pour ceux qui aiment vraiment le cadre, ce ne sont pas des problèmes. Et à tous les autres qui pensent également que Symfony est un excellent moyen de faire des choses simples par le biais d'un triple-ass, je vous félicite sincèrement - vous n'êtes pas seul. Bienvenue.