Tutoriel Vidéo Laravel Symfony Laravel ou Symfony ?

Télécharger la vidéo

Voici une question qui revient assez souvent sur le site en ce moment ? Malheureusement il n'est pas possible d'y répondre simplement et vous déclencherez suremenent une petite guerre de clan en la posant. Personnellement, je pense que ces 2 frameworks ont leur place dans l'écosystème PHP et que le choix de l'un ou l'autre doit se faire en fonction de vos préférences en tant que développeur sachant qu'il est possible d'être très productif avec l'un comme l'autre.

Le même coeur : Le Service Container

Tout d'abord il faut savoir que les 2 frameworks, bien qu'ayant une approche complètement différente au niveau des méthodes fournies, renferme le même système de Service container pour faire communiquer les différents composants ensemble. Si par exemple on veut générer une page :

// Sur laravel
view('posts/index'); // On fait appelle à une fonction globale

// Sur Symfony
$this->render('posts/index.html.twig') // On fait appelle à une méthode sur le controller

Bien que très différentes ces 2 méthodes éxécute un code relativement similaire derrière :

// Sur Laravel 
// view('posts/index');
Container::getInstance()->get('view')->make('posts/index');

// Sur Symfony
// $this->render('posts/index.html.twig')
$this->container->get('twig')->render('posts/index.html.twig')

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 rende le container accessible n'importe où dans l'application gràce à l'utilisation d'un Singleton, là ou Symfony imposera une plus grande rigueur en forçant l'utilisateur à spécifier les dépendances via un fichier services.yml.

Twig vs Blade

Les 2 frameworks proposent un moteur de template 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 tel 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 template 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'extension pour rajouter des fonctionnalitées. Cette approche rend aussi les templates plus simplement éditable par le développeur front-end (la syntaxe est plus simple et ressemble à du JavaScript). Blade est plus facile à prendre en main car 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 vs 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 persistence 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)

Un code vaut mieux que de longues explications...

/**
* Laravel
**/ 
// update
$post = Post::find(1);
$post->name = "Marc";
$post->save();
// create
$post2 = Post::create(['name' => 'Jean']); 
// destroy
$post3->destroy(); 

/**
* Symfony
**/ 
$em = $this->getDoctrine()->getManager(); // entity Manager
// update
$post = $em->getRepository('AppBundle:Post')->find(1);
$post->setName('Marc');
// create
$post2 = new Post();
$post2->setName('Jean');
$em->persist($post2);
// destroy
$em->remove($post3); 
// On persiste toutes les opérations précédentes
$em->flush();

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é au même endroit. Doctrine permet naturellement une meilleur 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 (plutôt que d'utiliser les scopes par exemple) 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ée le code de base à votre place.

FormBuilder vs FormRequest

Sur la gestion des formulaire et des données les 2 frameworks 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ée à 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. On regrettera la suppression du helper Form dans laravel 5.X qui rend la génération de formulaire relativement pénible.

Bundle vs ServiceProvider

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

Laravel ne dispose pas d'un tel système mais il est tout à fait possible de l'imiter avec utilisation les 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 (comme le fait par exemple laravel-debugbar). Cette séparation n'est pas aussi prononcée que Symfony 2 mais elle reste possible.

Donc Symfony ou Laravel ? les 2 !

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 racourcis. Mais avec un peu de rigueur il est possible d'avoir un code propre et une bonne organisation de 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 (rien ne vous empèche de faire du code dégueulasse ceci dit :)). Une fois passé 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.

Au final le choix va surtout dépendre de votre affinité vis à vis de la méthode utilisée :)