Laravel vs Symfony : sont est actuellement en tête du classement des Framework PHP côté serveur de plus de 79%, Laravel et Symfony étant les choix les plus populaires parmi eux. Dans cet article, nous examinons leurs avantages et leurs inconvénients.
Pour faire simple résumons rapidement les énormes différences entre ces deux Framework, les deux principales résidences résident dans l’architecture du code et dans la modularité. En effet, avec Symfony on peut « construire » des composants réutilisables, tandis que Laravel utilise une architecture plus classiqueModel View Controller.
Si vous envisagez d’utiliser un framework PHP ou d’externaliser votre développement PHP pour votre nouvelle application côté serveur, vous serez probablement confronté à un choix entre les deux leaders actuels du marché, Symfony et Laravel. Puisque Laravel est en fait basé sur Symfony et partage les mêmes composants de base, les avantages distinctifs de chaque framework peuvent être difficiles à comprendre.
Symfony est basé sur des projets PHP open source tels que Propel, Doctrine, PHPUnit, Twig et Swift Mailer. Bien qu’il ait ses composants, tels que Symfony YAML, Symfony Event Dispatcher, Symfony Dependency Injector et Symfony Templating. Symfony s’est imposé comme un framework de plus en plus fiable et mature. Il est principalement utilisé pour des projets commerciaux complexes.
Laravel est un framework open source qui suit le modèle de conception modèle-vue-contrôleur. Il réutilise des composants existants de différents frameworks pour créer des applications Web. Il comprend également les fonctions de base du framework PHP, telles que Yii, CodeIgniter ou Ruby on Rails. Si vous avez une bonne compréhension de Core PHP et Advanced PHP, Laravel sera beaucoup plus facile pour vous. Il est connu pour son codage simple qui se rapproche et réduit le délai de développement, ce qui est idéal pour développer des applications PHP simples.
Les idées fausses courantes que nous allons voir sont que Laravel s’exécute plus rapidement, est plus facile à mettre en œuvre au départ, et dispose d’une excellente documentation en ligne et d’une courbe d’apprentissage plus conviviale.
Il convient mieux aux projets qui nécessitent une mise en œuvre rapide, une portée moins complexe ou une grande évolutivité. Dans le même temps, Symfony nécessite un engagement initial plus important, mais peut permettre une réutilisation du code plus efficace et produire des applications Web plus robustes et évolutives au niveau de l’entreprise.
Aucune organisation vraiment neutre ne compare de manière égale les implémentations à grande échelle entre les deux frameworks, de sorte que les comparaisons de performances sont inévitablement anecdotiques. Néanmoins, en ce qui concerne le développement PHP d’entreprise, nous explorerons les avantages de chaque méthode et certaines des différences entre elles.
Pourquoi PHP ?
Le langage de script open-source côté serveur PHP a connu un parcours souvent douloureux vers le sommet depuis sa création en 1994. Avec JavaScript et Flash, il était devenu, au début des années 2000, l’une des technologies Web les plus ridiculisées. Souvent critiqué comme langage «amateur», PHP.8 semblait incapable de s’adapter à sa popularité croissante en termes de sécurité, de performances et de fonctionnalités.
Mais tout comme la réapparition de JavaScript via JQuery et la disparition de Flash, PHP a finalement conquis le cœur de nombreux critiques grâce à une coopération open source à long terme, des feuilles de route audacieuses pour la gestion des versions, le développement et l’adoption massive, et des frameworks hautes performances. Ceux-ci incluent Laravel, CakePHP, Symfony, Zend Framework, FuelPHP, PHPixie et Phalcon.
Laravel vs Symfony : L’essor du framework PHP
Des frameworks efficaces et riches en fonctionnalités ont donné à PHP un certain nombre de nouvelles capacités et caractéristiques qui s’avéreraient essentielles pour l’adoption à grande échelle et en entreprise. Les avantages comprennent :
- la disponibilité accrue des développeurs qui résulte d’une adoption à grande échelle
- la possibilité d’organiser et de réutiliser le code
- la capacité de développer plus rapidement des projets évolutifs et résilients
- un écosystème mature d’outils de support et de ressources tierces
Le résultat est qu’au moment de la rédaction de cet article, PHP est en tête du classement des langages côté serveur avec un taux indiscutable de 79.1%, devançant le concurrent le plus proche, ASP.NET, avec une marge de 69,9%.
PHP alimente certaines des entités Web les plus influentes de la planète, notamment Facebook (via HVVM), WordPress (qui représente actuellement 39,6% de tous les sites Web ), Wikipedia, Flickr et Tumblr. Il dessert également le demi-milliard d’utilisateurs de la plate-forme de médias sociaux vk.com, ainsi que le département d’État américain, qui a récemment abandonné ASP.NET pour PHP.
Parmi les frameworks côté serveur dérivés de PHP, Laravel et Symfony ont développé une avance constante au cours des dernières années. Puisque Laravel est construit sur la deuxième itération de Symfony (Symfony 2, sorti en 2011), il n’est pas surprenant que leur mission se recoupe beaucoup.
Laravel vs Symfony: origines et intention
Symfony
Inspiré du Java Spring Framework, Symfony a été créé en 2004 par un ingénieur logiciel de la société française SensioLabs et sorti sous licence MIT l’année suivante. La première version stable est apparue en 2007, Symfony2, qui a complètement réécrit la base de code en 2011, prouvant l’étincelle originale de Laravel (voir ci-dessous).
Symfony est hautement modulaire et est souvent utilisé comme ressource de bibliothèque de composants plutôt que comme framework complet. Le créateur Fabien Potencier l’a décrit comme « un ensemble de composants PHP indépendants, découplés et cohérents réutilisables qui peuvent résoudre les problèmes courants de développement Web ».
Les sites et projets développés à partir de Symfony (à l’exception des concurrents directs tels que Laravel, Yii et CakePHP) incluent Drupal, Spotify, DailyMotion et le référentiel européen de logiciels spatiaux de l’ESA. Les projets qui utilisent des composants Symfony incluent phpBB, Wikimedia, PHPMyAdmin, ainsi que les principaux packs d’installation Laravel / Symfony et de gestion Composer.
Au moment de la rédaction de cet article, Symfony est actuellement estimé comme une technologie de support ou de base derrière 53 011 sites Web en direct , et sa version actuelle est 5.2.1
Laravel
Laravel est comparé à une version orientée PHP des concepts de base de Ruby on Rails. Les tentatives précédentes pour simuler l’élégance et la facilité d’utilisation de RoR basé sur PHP incluent CakePHP et CodeIgniter. En fait, Laravel a été créé par le développeur de l’Arkansas Taylor Otwell, répondant directement aux limitations qu’il a vues dans CodeIgniter, telles que le manque de prise en charge de l’intégration continue (CI).
Laravel est plus engagé dans un paradigme de contrôleur modèle-vue (MVC) efficace que Symfony. Bien que ces deux frameworks soient souvent cités comme exemples du modèle architectural MVC, les créateurs de Symfony ont rejeté cette comparaison :
Je n’aime pas MVC car ce n’est pas ainsi que fonctionne le Web. Symfony2 est un framework HTTP; c’est un cadre de demande / réponse. C’est le gros problème. Les principes fondamentaux de Symfony2 sont centrés sur la spécification HTTP.
Fabien Potencier, Symfony SAS
Bien que ce serait trop reducteur de décrire Laravel comme «compilé», il est certainement optimisé pour le prototypage et le déploiement de développement rapide. Il s’agit d’un détournement conceptuel de bas niveau dans l’intention, et sans doute la plus grande différence entre les deux systèmes : Laravel a été créé comme un bourreau de travail pour les applications Web côté serveur, et non comme un tableau à la carte de ressources de bibliothèque discrètes (ce que Symfony peut être utilisé comme).
En ce sens, Laravel existe en aval de la prestigieuse liste de projets dont Symfony peut se vanter, dont beaucoup sélectionnent les technologies de base de Symfony plutôt que de les utiliser comme framework. De plus, Laravel est en soi une descendance de Symfony. Par conséquent, une comparaison à l’identique de l’absorption entre les deux cadres n’est ni possible, ni raisonnable.
Les sites et applications développés avec Laravel incluent InvoiceNinja, TrafficJunky, Zoom, Aimeos, Handesk, Lead Management App, Pricefy et Statamic CMS, parmi beaucoup d’autres. Au moment de la rédaction de cet article, on estime actuellement que Laravel est une technologie de support ou de base derrière 640 792 sites Web en direct , et sa version actuelle est de 8.x
Laravel vs Symfony : Laravel est-il plus rapide que Symfony au Runtime?
Il est difficile de prouver que Laravel surpasse l’opinion populaire de Symfony en termes de performances d’exécution. Les sources disponibles ne sont pas impartiales, et un grand nombre de changements de version dans ces deux frameworks au cours des 3-4 dernières années ont rendu plusieurs de ces comptes obsolètes. En outre, il n’existe aucun service d’analyse comparative objectif, puissant ou riche en ressources pour fournir des résultats significatifs dans une gamme de scénarios potentiels.
Aucun processus de test de référence ne peut prendre en compte les différences inévitables entre la configuration matérielle et réseau, la dépendance d’un tiers vis-à-vis d’une technologie ou d’un flux de données non pertinent (c’est-à-dire (c’est-à-dire un flux de données basé sur le cloud) la dépendance aux retards), les différences de quantité et de fréquence. (Trafic de pointe ), etc.), la latence géolocalisée (distance aux datacenters clés) et l’efficacité de conception (base de données et/ou principalement atteinte).
Même si vous pensez que Laravel a été fréquemment cité dans ses performances au cours des cinq dernières années environ, la marge des citations habituelles (50 contre 250 millisecondes, Laravel sur Symfony) peut être insignifiante pour votre modèle et les exigences proposées. Dans le contexte du temps et du coût de développement, la « vitesse » peut être considérée de manière plus appropriée (voir ci-dessous).
Laravel vs Symfony : Cartographie relationnelle d’objets (ORM)
Le mappage objet-relationnel (ORM) fournit des méthodes de haut niveau pour accéder à une variété de types de bases de données. Il résume les requêtes, opérations et fonctions basées sur SQL dans le modèle de programmation orientée objet (POO). Cela permet le développement plus rapide d’un code plus propre, plus transparent et plus responsable lié aux requêtes de données.
Laravel: ORM éloquent
Laravel utilise Eloquent ORM, qui prend en charge quatre types de base de données prêts à l’emploi: MySQL, PostgreSQL, SQLite et SQL Server (ainsi que SQL brut). Eloquent utilise le modèle Active Record, permettant aux développeurs de rassembler facilement des transactions de création, de lecture, de mise à jour, de suppression (CRUD) et de faire des requêtes économiques de «vérification sale» qui ne rapportent que les éléments modifiés dans la base de données.
Eloquent n’a pas la capacité de Doctrine d’éviter les scénarios de migration en utilisant des schémas de «pont» (voir ci-dessous). Cependant, il peut faciliter les migrations sans qu’il soit nécessaire de définir des champs dans le modèle – un outil que Doctrine n’a pas.
Bien qu’Eloquent soit perçu comme l’une des principales forces de Laravel, il a également été critiqué pour ne pas rester performant à grande échelle et pour ne pas séparer la logique métier de l’architecture de base de données.
En ce qui concerne les performances, cependant, beaucoup admettent que le compromis d’Eloquent entre facilité et vitesse (et le fait qu’il est inévitablement plus lent à l’exécution que le SQL brut) est un échange équitable. Les développeurs utilisent souvent du SQL brut ou Query Builder pour soulager les goulots d’étranglement d’Eloquent dans certaines parties de la base de code.
Symfony: Doctrine ORM
Symfony utilise le tiers Doctrine ORM, qui est également utilisé par d’autres frameworks notables tels que Yii, Zend et CodeIgniter. Doctrine est découplée des composants de Symfony et peut accueillir un large éventail de types de bases de données potentiels, bien que les composants ne fournissent pas explicitement de support natif pour un schéma particulier.
Doctrine peut éviter le besoin de migrations de bases de données en créant un schéma adaptatif une fois que vous avez défini un modèle de parité approprié.
Le modèle de mappeur de Doctrine crée une division très claire entre le schéma de base de données et le fonctionnement logique de l’application. En revanche, Eloquent peut souvent créer des liens inconfortablement étroits entre le schéma et l’application.
Cependant, Doctrine nécessite la création d’une fonction de référentiel pour chaque appel qu’elle fait. Celles-ci peuvent rapidement s’intégrer dans des applications plus complexes, ce qui rend la gouvernance de code potentiellement plus lourde qu’avec Eloquent.
Bien que les développeurs soient plus susceptibles d’avoir de l’expérience avec les packages par défaut de l’un ou l’autre framework, Eloquent et Doctrine peuvent être utilisés dans Laravel ou Symfony selon les besoins.
Générateur de requêtes
Lorsque l’on considère Laravel et Symfony, il faut considérer que ce dernier dispose de puissants outils supplémentaires de demande. Query Builder n’a pas l’intégrité du modèle Eloquent, ainsi que bon nombre de ses fonctionnalités les plus utiles, telles que la gestion des relations, les modificateurs, les accesseurs et les horodatages automatiques. Cependant, il présente un avantage de vitesse unique dans l’exécution des requêtes et des transactions CRUD.
Modèles de moteurs : Twig vs Blade
Comme avec Eloquent et Doctrine, il est possible de mélanger et de faire correspondre Twig et Blade, les deux moteurs de template standard de Laravel et Symfony, via ce projet GitHub et le référentiel TwigBridge .
Les deux moteurs de modèles implémentent des blocs / sections et l’héritage de modèle. Avec Twig, cependant, les fonctions doivent être définies deux fois, à la fois pour le modèle et pour le contrôleur. Cela peut entraîner un niveau de spécificité fastidieux et une certaine difficulté dans la réutilisation du code par rapport à Blade.
Contrairement à Symfony, Laravel s’est engagé à exploiter toute la diversité des fonctionnalités PHP plutôt que de s’en tenir aux fonctions de plus haut niveau qui permettent d’exploiter Symfony en tant que ressource de bibliothèque. Encore une fois, il s’agit d’une décision de conception et non strictement d’un «avantage»: l’utilisation par Laravel de la fonctionnalité plus idiosyncratique de PHP fait également l’objet de critiques occasionnelles.
Cependant, cela signifie que Blade peut utiliser des fonctions PHP directement dans sa logique de création de modèles, de sorte que le code soit reflété dans le code du contrôleur. Les services peuvent également être instanciés directement dans un modèle avec la commande @inject, un gain de temps réel.
Néanmoins, l’installation de Blade se fait au prix de brouiller un peu le modèle MVC, car l’introduction de la logique des données dans la couche de présentation affecte dans une certaine mesure la portabilité et la transparence. Puisque Twig utilise un modèle plus portable, il a une vie active en dehors de Symfony, ce qui augmente la base de développeurs qui s’y familiarise.
Blade propose également Lumen, un sous-framework utile pour les microservices et les API. Les fonctionnalités de Lumen peuvent être répliquées dans Symfony, mais pas de manière aussi élégante.
Intégration continue dans Laravel et Symfony
L’intégration continue (CI) automatise les processus de re-test et de validation qui deviennent nécessaires lorsque la base de code est modifiée. Laravel et Symfony prennent en charge nativement les mêmes six modèles CI :
- Jenkins, via GitHub (avec des modèles dédiés disponibles pour Laravel et différentes versions de Symfony)
- Travis et Drone, à la fois des CI basés sur Git et indépendants du framework
- Style, qui a des modèles pour Laravel et Symfony
- Circle, qui fournit également des modèles Laravel dédiés
- CodeShip, accessible via Git, avec des paramètres valides
Laravel vs Symfony : validation de formulaire
Laravel et Symfony abordent la validation des formulaires de manière assez différente. La validation de Laravel se produit contre une entrée, soit à partir d’un formulaire, soit à partir d’une validation de demande manuelle. Le composant Symfony Validator, qui fournit une gamme plus large de services de validation générale, effectue l’opération via l’instanciation d’une classe de Validation , validant efficacement un modèle sur la POO base.
Laravel propose également un hook After Validation flexible, offrant un avantage supplémentaire dans la gestion des erreurs. Dans Symfony, cela nécessiterait une nouvelle instance du validateur (et des fichiers supplémentaires à créer) afin d’atteindre le même objectif. Cependant, les partisans de Symfony ont soutenu que la validation des entrées brutes de l’utilisateur devrait, dans tous les cas, relever des propres routines de validation du formulaire, et que l’approche de plus haut niveau adoptée par Symfony est supérieure en ce qui concerne les traductions.
Ici, pas pour la première fois, la différence entre Laravel et Symfony semble se résumer à la tension entre la facilité d’utilisation (Laravel) et le maintien de l’intégrité d’un modèle découplé de plus haut niveau (Symfony) des thèmes qui sous-entendent les principes fondamentaux et les intentions des deux frameworks, respectivement.
Laravel vs Symfony : courbe d’apprentissage
En raison de sa détermination à fournir des composants portables, découplés et flexibles, Symfony est généralement perçu comme ayant une courbe d’apprentissage plus élevée que Laravel. Cette considération est exacerbée par la quantité supérieure de matériel d’apprentissage en ligne et de ressources disponibles pour Laravel.
Pour 99 $ par an, les utilisateurs peuvent s’abonner à tout le contenu de Laracasts, une énorme ressource communautaire qui fournit des forums ouverts et des didacticiels vidéo. La plupart du contenu est disponible sans abonnement. Le domaine compte actuellement plus de 65 000 threads, tandis que les forums laravel.io complémentaires (et gratuits) proposent plus de 15 000 sujets.
Symfony a un Slack Chat actif et une gamme très respectée et bien ordonnée de documentation en ligne. Cependant, il a détourné les efforts antérieurs de développement du forum vers Stack Overflow.
Au moment de la rédaction de cet article, Stack Overflow approche les 164 698 questions questions liées à Laravel, moins d’un tiers des questions liées à Symfony (67 760) dans ce domaine. Que ce soit parce que les ressources dédiées de Laravel sont plus convaincantes, ou que Symfony est plus technique (ou demande plus de connaissances !) La question est ouverte à l’interprétation.
SensioLabs, le créateur de Symfony, propose un support payant pour la suite, alors que le conseil professionnel autour de Laravel n’est disponible que via des sociétés indépendantes.
Laravel vs Symfony : Conclusion
Laravel reste un projet enfant de Symfony. Il a intentionnellement abandonné certaines des fonctionnalités de développement les plus attrayantes de son ancêtre en échange de la possibilité de fournir un prototypage et un déploiement rapides. Cependant, certains des raccourcis qui facilitent ses flux de travail de développement rationalisés (comme la diminution de la distinction entre les données et la conception dans certains aspects du cadre) pourraient poser des problèmes à un projet s’il devait un jour évoluer plus haut que prévu initialement.
Laravel est toujours un sous-projet de Symfony. Il a délibérément abandonné certaines des caractéristiques de développement les plus attrayantes de ses ancêtres en échange de la capacité de fournir un prototypage et un déploiement rapides. Cependant, certains raccourcis qui aident à simplifier le flux de travail de développement (tels que la réduction de la différence entre les données et la conception dans certains aspects du framework) peuvent causer des problèmes pour le projet s’il est plus volumineux que prévu à l’origine.
L’intégrité de conception de Symfony permet de rentabiliser un investissement initial en temps et en argent plus important grâce à une mise en œuvre de projet plus stable et évolutive. Si vous êtes impressionné par les utilisateurs stables bien connus de Symfony, il convient de rappeler que peu de grands noms de cette liste utilisent Symfony comme framework de base. Étant donné que sa mission est divisée en fournissant des modules et des frameworks cohérents, Symfony peut être considéré comme ayant moins d’intégrité conceptuelle que Laravel.
Alors que le framework Symfony résout ce problème dans chaque version, l’avantage de vitesse d’exécution à long terme (peut-être falsifié) de Laravel semble s’éroder. Par conséquent, les principaux facteurs que Laravel recommande à Symfony sont sa courbe d’apprentissage plus facile, ainsi qu’une documentation en ligne et une communauté de développeurs très complètes.
Les comparaisons entre les frameworks PHP ont toujours existé, et il n’y a pas de moyen exact de déterminer celui qui convient le mieux à tout le monde. Les deux ont des similitudes et des différences.
Tout dépendra de vos besoins et de votre projet, et comprendre les avantages de chacun vous permettra de choisir le meilleur ! Lorsque vous avez besoin d’un support PHP professionnel, nos développeurs PHP sont prêts à vous servir. Discutez de votre projet et suggérez de choisir la bonne pile technologique pour votre projet.
