Un Framework, de quoi s’agit-il ?

Pour bien commencer, il est important de comprendre la notion de Framework. Un Framework est une « boite à outils » à destination du développeur. Il a pour but de faciliter la programmation et la conception d’un logiciel.

Ici, je vais vous présenter deux Framework PHP : Symfony et Laravel, avec les avantages et les inconvénients de chacun.

---

Tout d’abord, il faut savoir que les 2 Framework, bien qu’ayant une approche complètement différente au niveau des méthodes fournies, renferment le même système de Service Container pour faire communiquer les différents composants ensemble.

Dans les 2 cas, le Framework va commencer par créer un Container qu’il va ensuite remplir de différents services qui pourront ensuite être récupérés suivant les besoins au sein de l’application. Laravel se différencie alors de Symfony par le fait qu’il rend le Container accessible n’importe où dans l’application grâce à l’utilisation d’un Singleton, là ou Symfonyimposera une plus grande rigueur en forçant l’utilisateur à spécifier les dépendances via un fichier services.yml.

Twig / Blade :

Les 2 Framework proposent un moteur de templates afin d’écrire les « vues » HTML.

• Laravel propose d’écrire des fichiers .blade.php qui sont des fichiers PHP avec quelques méthodes supplémentaires pour vous simplifier la vie, telles que @foreach ou @extends. Le code à l’intérieur des balises Blade doit avant tout être du code PHP valide.
• Symfony utilise le moteur de templates Twig qui, lui, propose une syntaxe complètement différente du PHP (post.name au lieu de $post->name) qu’il est possible d’étendre grâce à l’utilisation d’extensions. Il n’est pas possible de faire appel à n’importe quelle classe PHP depuis le template directement.

Pour résumer, Twig est un moteur plus puissant mais qui est aussi plus contraignant en imposant l’utilisation d’extensions pour rajouter des fonctionnalités. Cette approche rend aussi les templates plus facilement éditable par le développeur front-end. Blade est plus facile à prendre en main car il permet d’écrire du PHP dans des cas spécifiques, avec le risque parfois de voir des appels aux models directement dans les vues.

Doctrine / Eloquent :

L’ORM est aussi un gros point de différence jusqu’au paradigme utilisé.

• Laravel utilise par défaut Eloquent, qui est un ORM basé sur Active Record, où le Model est à la fois responsable de représenter une entité mais aussi de gérer la persistance des informations.
• Symfony utilise par défaut Doctrine, qui est un ORM basé sur le principe du Data Mapper, où on sépare la notion d’entité (objet représentant les données), de Repository (objet servant à récupérer des entités) et de Manager (objet responsable de la persistance).

Eloquent a une syntaxe plus courte et une logique qui semble plus naturelle, mais cette apparente simplicité peut rapidement mener à des « fat models » car toute la logique va être stockée au même endroit. Doctrine permet, naturellement, une meilleure séparation mais s’avèrera relativement verbeux pour des cas simples.

Il n’y a pas de bon ou de mauvais choix :

• Pour Eloquent, vous pouvez gérer un code qui « grossit » en séparant la logique de récupération en Repository afin de garder un code plus léger.
• Pour Doctrine, la complexité de la structure est mitigée par des générateurs qui créent le code de base à votre place.

FormBuilder / FormRequest :

Sur la gestion des formulaires et des données, les 2 Framework ont une approche complètement différente.

• Symfony permet de créer une classe qui va gérer les formulaires, depuis leur création jusqu’au traitement des données. Le formulaire sera même capable d’hydrater une entité à partir des données reçues.
• Laravel propose simplement un type de Request particulier permettant de vérifier et de traiter les données reçues lors d’une requête. Il faudra alors manuellement traiter les données et modifier le modèle en fonction.

Bundle / ServiceProvider :

Symfony est connu pour disposer d’un système de Bundle permettant l’ajout de fonctionnalités supplémentaires avec une bonne séparation du code.

Laravel ne dispose pas d’un tel système mais il est tout à fait possible de limiter avec l’utilisation des ServiceProviders, qui disposent d’une méthode boot() qui se lance au démarrage du Framework. Il est ainsi possible de créer une librairie dans un namespace séparé et d’inclure une logique dès l’importation du ServiceProvider. Cette séparation n’est pas aussi prononcée que Symfony mais elle reste possible.

Quelques chiffres :

Symfony	Laravel
Année de lancement	2011	2011
Version Actuelle	4.0	5.6.15
Dispose de version LTS	Oui	Oui
Licence	MIT License	MIT License
Nombre de Package*	7,500	16,900
Nombre de projet open sources	25,300	76,200
Nombre de Question sur Stack Overflow	56,885	88,338
Nombre d’étoile Github	17,600	43,100
Nombre de contributeurs	1,645	446

* Information à mettre à jour.

Symfony ou Laravel ?

Laravel se focalise sur la simplicité du code pour le développeur (arriver à la solution simplement), ce qui peut parfois emmener à de mauvaises pratiques lorsque l’on veut prendre des raccourcis. Mais avec un peu de rigueur, il est possible d’avoir un code propre et une bonne organisation de ce code. L’utilisation d’un Service Container permet de gérer l’injection de dépendance et ainsi de s’assurer que le code reste facilement testable.

Symfony impose plus de rigueur en ne masquant pas la complexité du Framework derrière des façades, et est donc plus complexe à appréhender. Il possède une courbe d’apprentissage un peu plus longue mais a l’avantage d’imposer plus de barrières. Une fois passées la phase d’apprentissage et la découverte des différents Bundle fournis, le Framework reste très agréable à utiliser et permet d’être aussi productif qu’avec Laravel.

Personnellement, je me sens plus à l’aise avec Symfony. Certes, il est plus compliqué à prendre en main, mais, une fois les bases acquises, il permet une vraie optimisation et augmente considérablement la rapidité de développement, tout en gardant une certaine rigueur dans l’organisation des projets.

---

Sources :
https://www.quora.com/How-different-is-Laravel-from-Symfony-when-Laravel-was-built-using-Symfony-What-do-they-do-differently
https://www.grafikart.fr/tutoriels/php/laravel-symfony-866
https://stackoverflow.com
http://symfony.com/doc/current/contributing/community/releases.html