Guide du développeur Symfony 3 pragmatique

Symfony2 est réputé être un framework plutôt facile à prendre en main. En revanche, garder une cohérence d'ensemble dans l’architecture de son projet n'est pas chose aisée. Voici une petite synthèse des choses à retenir. Quelques semaines avant la sortie de Symfony3, il est toujours bon de faire une petite mise au point pragmatique...

Attention, cet article date de plus de 2 ans maintenant... Il est possible que les infos publiées ne soient plus correctes aujourd'hui...

Construire son projet Symfony

La structure d'un projet Symfony

Symfony3 pointe le bout de son nez, et Fabien Potencier avait annoncé dans sa feuille de route que la migration d'un Symfony2 vers un Symfony3 se ferait facilement et délicatement. c'est la parfaite occasion pour ouvrir la discussion sur les pratiques de développement d'un projet Symfony.

Une bonne architecture est essentielle pour faciliter l'évolution et la maintenance de son projet. Il est préconisé de définir un nombre restreint de bundle. Vous devez utiliser des "namespace" standards et non typés pour faciliter la réutilisation, le cherry pick du code et simplifier le découpage de votre projet. La construction proposée dans cet article est toujours en débat au sein de la communauté Symfony qui s'oriente, peu à peu, vers une structure sans Bundle.

  • AppBundle : Gére la partie Frontend du projet
  • AdminBundle : Contient le backoffice

Il n'est pas obligatoire d'avoir un bundle spécifique pour l'administration. Cela dépend en grande partie de la philosophie de votre projet, de votre rigueur, du nombre d'intervenants sur le projet et des interdépendances entre votre FrontOffice et votre BackOffice. Ainsi plus communément, vous pouvez conserver uniquement le bundle App pour votre projet.

Depuis Symfony 3, le cache, les logs et le bootstrap cache seront disposés dans le dossier var/. La console est présente depuis le dossier bin/.

Récapitulatif d’arborescence de base :

  • app - les configurations, vues et les assets globales (jquery, boostrap,...);
  • bin - les scripts de gestion symfony 3;
  • src - les bundles de votre projet;
  • var - les logs et le dossier de cache;
  • vendor - les bundles (vendors) externes;
  • web - les fichiers "publics" de votre projet.

Vos vendors favoris pour votre projet Symfony

Pour certaines fonctionnalités et besoins, l'utilisation de certains bundles existants est recommandée. En effet, si celui-ci est léger et ne réalise qu'une et une seule chose correctement, il permet de s'affranchir d'un développement qui ne sera pas forcément meilleur et générateur de bugs.

Nos bundles "essentiels" :

Les recommandés :

François, de l'équipe Wanadev, avait il y a quelques temps déjà listé quelques bundles intéressants pour l’amorçage d'un projet Symfony. Depuis sa publication, nous avons un peu revu cette liste, mais elle reste globalement bonne pour démarrer !

My bundle is rich

La structuration de votre bundle est plus importante qu'elle en a l'air. En effet, respecter une bonne logique dans l'organisation de votre bundle facilite le développement collaboratif et facilite la maintenance de votre projet. Pour une vision simple et claire, vous pouvez utiliser une sous-arborescence reprenant les grands blocs fonctionnels de votre projet:

tree1Dans le cas d'un bundle administratif fusionné (backoffice dans AppBundle), il est conseillé de mettre en place cette autre arborescence (notre recommandation) :

tree2 Voici les principaux dossiers de votre bundle :swimming-in-money

Command : Les commandes ou tâches vous permettent d’effectuer des traitements sur votre projet qui sont exécutés directement en ligne de commande. Souvent utilisé pour mettre en place des routines (maintenance de la base de données, système de notification...), vous ne devez pas oublier que n'avez pas de contexte lors de l’exécution de ces scripts et donc pas d'accès "request" par exemple.

Controller : Le controller contient les routers de votre application qui réalise le pont entre la "request" HTTP et la "response" HTTP renvoyée.

DataFixtures : Stocke les fixtures du projet (jeu de données).

Entity : Les déclarations de vos entités.

Repository : Les Repository gèrent les requêtes DQL ou SQL liées aux entités.

Listener : Les Listeners vous permettent d'exécuter du code lors d'un événement du déroulement des pages.

Form : Les formulaires de votre projet.

Manager : Le code métier ou des traitements spécifiques. Les managers permettent de centraliser du code qui pourrait être appelé par plusieurs controllers par exemple.

Resources :

  • config : Ce dossier stocke vos déclarations de service, les paramétrages et la configuration de votre bundle au format yml (notre recommandation) ou xml.
  • public :  Contient les assets comme vos images, vos feuilles de style et vos JavaScripts. Avec la gestion des assets Symfony, les éléments contenus dans ce dossier sont accessibles par tous.
  • views : pour gérer facilement vos  templates, vous devez respecter  l'arborescence de vos controllers. Pour le nommage des fichiers twig, simplifiez-vous la vie au maximum : index.html.twig, edit.html.twig, show.html.twig... Si votre arborescence est bien conçue, ne rajoutez pas le nom de l'entité associé : show_post.html.twig. Pour améliorer la lisibilité de ce dossier, ajouter des "_" devant vos partials : _items.html.twig

Pour votre gestion des assets, vous pouvez utiliser des outils comme GULP, GRUNT pour gérer des tâches de compilation et de minification des fichiers JS ou CSS. Malgré tout, Assetic proposé par défaut reste une solution. Nous conseillons aussi d'utiliser un gestionnaire de librairies comme BOWER. N'hésitez pas à séparer vos ressources spécifiques de chacune de vos pages pour ne pas surcharger vos fichiers JS et CSS génériques. Pour une écriture CSS scalable et optimisée, nous préconisons d'utiliser SASS ou LESS.

Gestion des utilisateurs

Nous déconseillons l’utilisation d'un bundle spécifique pour gérer vos utilisateurs. Pour une meilleure maitrise des mécanismes et des formulaires, il est préférable d’utiliser le système natif symfony. Les possibilités offertes par défaut dans Symfony permettent de réaliser rapidement (et avec plus de maitrise) les mécanismes "utilisateur" de base.

Bonnes pratiques

Nous publierons prochainement un article qui traitera des bonnes pratiques dans l'écriture du code pour Symfony.

Retrouvez dès à présent des ressources complémentaires pour améliorer vos pratiques :

http://symfony.com/doc/current/quick_tour/the_architecture.html http://elnur.pro/symfony-without-bundles/ https://www.wanadev.fr/category/symfony2-2/

Enfin, nous vous invitons à réagir à cet article, en nous partageant votre conception des bonnes pratiques d'architecture pour la bienséance d'un développement d'un projet Symfony. De notre côté, on se lance sur des projets Symfony3 ;) ! Racontez nous vos anecdotes !

Tags de
l'article

bonnes pratiques

Commentaires

Il y a 3 ans Répondre

« Nous déconseillons l’utilisation d’un bundle spécifique pour gérer vos utilisateurs. »

Le bundle FosUserBundle fait tout de même référence sur le sujet dans le monde Symfony …

Manuel

Il y a 3 ans

Nous ne remettons pas en cause la qualité même de FOSUserBundle mais son utilisation systématique sur les projets. Symfony propose par défaut de s’affranchir rapidement de ce bundle en proposant plus de liberté dans la gestion de ses utilisateurs.

theShadoo

Il y a 3 ans Répondre

@R.Kueny le bundle FosUserBundle vient effectivement souvent à l’esprit lorsqu’il s’agit de mettre en place une gestion d’utilisateur, MAIS, car il y a un mais et pas des moindres..
une question que l’on doit souvent se poser « La popularité d’un package n’est pas forcément synonyme de référence ». Hélas et quoi qu’il en soit, c’est en essayant un plugin, package, cms, framework ou bundle que l’on ne peut s’apercevoir de problématiques qui impacterait le workflow d’un développement d’application. .

Je suis tombé à deux reprises où je devais moi ou d’autres dev suffisamment avancé en poo, étendre ou bien imbriquer certaines fonctionnalités ou comportement lié à fosuserbundle qui au final s’avérait être très complexe et uzine à gaze dans le code de ce bundle..

Ce qui rendait sa compréhension afin de l’étendre ou d’ajouter certaines fonctionnalités, très complexe sur des projets selon le contexte..

Je ne dis pas non plus que le bundle est mal développé, car c’est un gros travaille qui a été effectué et son auteur a bien revue certaines problématiques afin de faire évoluer son code..

Alors que pour des résultats similaire en attente sur des projets, la gestion acl native de Symfony2 était plus rapidement mise en place et beaucoup plus facilement extensible que fosuserbundle. .

Donc en terme de facteur temps / résultat on était gagnant largement en rapport à l’utilisateur de fosuser. .

C’est d’ailleurs assez marrant notamment au niveau de l’architecture proposé par @Manuel Klein, car sur tous mes projets j’architecture exactement de cette façon et j’ai aussi le même point de vue que wanadev sur FosUserBundle de part mon expérience sur des projets et les problématiques rencontrés au fur et à mesure des mes expériences.

Je réalise à peu prêt la même structure applicative notamment lorsque je travaille avec d’autres framework (laravel / fuelphp). .

Au passage j’aime beaucoup votre blog car c’est rassurant de voir des articles exposants des problématiques ou pratique de conception en dev qui sont assez récurrentes et peut être cruciale dans le développement d’une entreprise. Mais par contre cela m’a couté ma place dans une entreprise le fait que je souligne l’importance des bonnes pratiques et d’une bonne architecture à mettre en place..

Résultat je m’étais fait viré au bout d’un moment car j’étais trop long pour eux à développer et ne comprenaient pas pourquoi je m’emmerdais à mettre en place des design patterns selon le besoin dans certains dossier de bundle :(

Il y a 3 ans Répondre

My bundle is rich : dans l’exemple d’architecture que vous donnez je préconiserais une scission de la fonctionnalité BLOG en 2 fonctionnalités utilisateur et blog dans 2 bundles : bundle user + bundle blog.

Manuel

Il y a 3 ans

Bonjour et merci pour ce commentaire. La tendance actuelle sur l’organisation d’un projet symfony penche à l’unification des bundles et la scission des fonctionnalités à l’intérieur même du bundle. Mais comme à chaque fois, rien ne vous oblige à respecter cette structure !

castanares

Il y a 3 ans Répondre

Bonjour, Je me pose actuellement la question sur l'organisation de mes fichier et je me trouve confronté à un problème qui n'a pas été cité (ce n'est pas une reproche loin de la juste moi qui cherche la complication :) ). Je souhaite faire un Usersbundle qui sera utiliser pour mon portfolio (site pour apprendre et tester symfony) mais je souhaiterais ne pas refaire se Bundle pour mon prochain site du coup je me demande quelle serait la meilleur structure pour ceci? J'avais penser faire le Bundle à coter du AppBundle, ce qui me permettra ensuite de faire un copier coller de UserBundle dans un autre Projet plus facilement. Car je n'arrive pas à trouver une solution avec l'architecture que vous proposer qui me permettrai de faire ceci. Je viens de découvrir votre site et je vous remercie pour toutes ces informations qui sont fort utile.

Manuel

Il y a 3 ans

Il n'est pas nécessaire d'isoler le bundle de gestion des utilisateurs dans ton projet. Dans le cas d'une utilisation d'un système du type FosUserBundle, il est en revanche obligatoire de réaliser un extend . C'est aussi pour cette raison que nous déconseillons l'utilisation de ce bundle (https://www.wanadev .fr/11-kit-de-survie-symfony2-gestion-utilisateur-sans-fosuserbundle/) Pour une réutilisation de ton code dans d'autres projets, il est préférable de faire du cherrypick pour te permettre de récupérer l'essentiel de ton code. Bon courage dans tes devs !

William

Il y a 2 ans Répondre

"Nous publierons prochainement un article qui traitera des bonnes pratiques dans l'écriture du code pour Symfony." ça fait quand même 7 mois... J'imagine pas si c'était pas précisé "prochainement", à mon avis on risquerait d'attendre :)

François

Il y a 2 ans

Bonjour William, 

7 mois ! Déjà 7 mois ! En effet, du code a coulé sous les ponts depuis cet article ! "Bonnes pratiques de développement Symfony3" : article / chimère qui, malgré tout, reste dans nos tuyaux (si si !).

En guise d'apéritif, pour tenter de rassasier votre faim d'assiduité et de rigueur sur les bonnes pratiques Symfony3, je vous invite à aller jeter un œil à quelques articles qui se rapprochent beaucoup de vos attentes :

- Comment réaliser de belles requêtes SQL avec Doctrine 

- Retours d'expérience : quels outils pour bien démarrer un projet Symfony

Retour d'atelier : Pourquoi et comment mettre en place Gulp sur un projet Symfony

- Retour d'atelier : Pourquoi et comment mettre en place ElasticSearch sur un projet Symfony

Nous ajoutons cependant à nos bonnes pratiques de publication d'articles : "Ne pas s'emballer sur le calendrier éditorial" ;-) !

Au plaisir de vous croiser ici, sur le blog ou sur Twitter.

Josué CHARLES

Il y a 2 ans Répondre

Je suis entrain d'apprendre symfony (v. 3.1.6). Je me sents inconfortable de ne pas gérer mes utilisateurs avec Fosuserbundle contrairement au tutoriel que je suis car l'auteur me recommande de le faire. Mais Vous conseillez de prendre soi-même en main la gestion des utilisateurs de son site. Je vous demanderais si on peut faire tout ce que  Fosuserbundle peut et j'aimerais avoir un lien vers la documentation de symfony 3.1 qui traite de la manière de "reset" le mot de passe d'un utilisateur. Merci de votre réponse!

François

Il y a 2 ans

Bonjour, merci pour votre commentaire.

FOSUSerBundle est en effet confortable : c'est rapide à installer, et ça marche. En revanche, il est aussi très rapide d'utiliser tous les composants "natifs" de Symfony pour en faire sa propre gestion d'utilisateurs, très rapidement.

Notre collègue Baptiste en a fait 2 très bons articles :

N'hésitez pas à revenir si jamais des questions subsistent ;-) !

Adrien (Ninj)

Il y a 2 ans

Bonjour Josué,

J'ai tenté d'expliquer avec quelques précisions les raisons pour lesquels le choix de FOSUser n'est pas une évidence. C'est encore plus vrai aujourd'hui, avec SF 3 qui a bien évolué, et FOSUser qui a plutôt stagné. C'est ici :

http://stackoverflow.com/a/13566162/1094177

Pour autant, c'est un bundle qui a son utilité, dans le cas de petits projets rapides et dont la gestion des utilisateurs est simple.

Articles liés