Symfony vs Laravel

Salut !

J’ai parcouru ton article, et force m’est de me demander si l’auteur originel connaît Symfony et l’utilise ou l’a utilisé, ainsi que de quand date l’article. J’ai suivi le lien que tu as mis dans la conclusion, et je n’ai pas réussi à trouver de date sinon dans l’URL d’une des images pour les méta Facebook, ce qui fait que je dirais début 2012. Autant dire que si c’est bien ça, de l’eau a coulé sous les ponts depuis… Mais passons.

Autant préciser de suite : si l’auteur originel est peut-être partial pour Laravel, moi je ne suis pas non-plus impartial, ne connaissant que Symfony 

Les choses qui me font me demander si l’auteur a testé ET utilisé Symfony sont les suivantes :

• les explications détaillées sont bien souvent pour les exemples Laravel ;
• il y a création d’une méthode pour persister un objet dans un repository, alors que c’est justement le rôle de l’ObjectManager ;
• la méthode pour notifier d’une création ne se repose pas sur les événements Doctrine (ici on pourrait simplement écouter prePersist ou postPersist, c’est selon), mais sur un service qu’il faut donc appeler "manuellement". Certes, c’est moins intuitif, mais ce serait justement la manière de faire avec Symfony ;
• l’image qu’il utilise pour comparer les événements avec les middlewares est un peu… particulière aussi. Si on peut comprendre que c’est compliqué avec Symfony, ça explique la méthode utilisée : on a des événements qui sont lancés avant que le contrôleur ne soit appelé, et d’autres après que le contrôleur soit appelé. Ces événements déclenchent des actions. OK.
  L’illustration pour Laravel montre juste que le contrôleur est entouré par les middlewares, mais ne précise pas par quel moyen, comme il l’est fait pour Symfony. Est-ce c’est de l’héritage, même si c’est avec des traits ? Ou est-ce une forme d’injection de dépendances (auquel cas j’aurais personnellement mis les middlewares dans le contrôleur) ? Il est bien fait mention de couches, mais pas plus en détail… ça me frustre 
• l’exemple pour l’API REST est là volontairement biaisé, dans la mesure où il dit clairement qu’il n’a pas suivi les conventions afin d’expliquer ce qu’il faut faire. Est-ce qu’il fait fi des raccourcis proposés par Laravel aussi, du coup ?
  Et là, on a même l’inverse du premier point que je relevais : il est très détaillé pour Symfony, ce qui me fait penser qu’il a recherché comment faire, mais il s’est rendu compte de ce que ça lui prenait plus de temps pour comprendre… donc forcément, ça le rebuterait un peu.

Après, je partage certains points de vue de l’article. Laravel me paraît à moi aussi :

• plus explicite, donc moins besoin de connaître la "magie" du framework ;
• plus proche du PHP "standard", notamment dans Blade où il est possible d’utiliser une fonction PHP de la SPL ;
• du coup plus "libre"…
• …et plus facile d’accès que Symfony.

Et pour terminer, il y a une petite erreur dans la traduction de la conclusion qui en fausse sa compréhension.

Ce qui a été traduit par :

Vous concevez une application dense qui doit être maintenable, bien structuré et personnalisable.

Ce qui fait penser que l’application doit être bien structurée. Or, dans la version originale, c’est Symfony qui est bien structuré. C’est d’ailleurs un des points que je mettrais en avant en cas de travail à plusieurs sur une application : les conventions et bonnes pratiques Symfony permettent de ne pas avoir à y réfléchir comme il pourrait l’être nécessaire quand on se lance avec Laravel.

Voilà voilà