Arborescence d’un projet PHP Symfony

Le dossier src d’un projet Symfony contient vos classes métiers et compose le coeur de votre application.

Les Best Practices de Symfony préconise une structure de base avec ce dossier src/ et quelques sous-dossiers.

Je vous propose ici le fruit de ces dernières années et des projets PHP réalisés avec le framework Symfony : il s’agit d’une arborescence des dossiers que j'ai pu trouvé dans les dossiers src.

Cette liste n’est pas là pour figer les choses et n’a rien d’officielle.

Le but de cette liste est de faire un référentiel pour :

• définir quels types de classe et services nous devrions trouvés dans chaque namespace correspondant à un sous-dossier du dossier src
• “trouver l’inspiration” quand vous n’avez pas de modèle de conception qui vous vienne spontanément à l’esprit.

Certains proviennent de la documentation Symfony ou de ses best-practices, d’autres d’habitudes tout à fait personnelles.

A

• Adapter : service qui converti un objet en un autre (c.f. Transformer s’il s’agit de donnée et non d’objet)
• Aggregator : service qui rassemble de la donnée depuis différentes sources
• ApiResource : dossier créé par API Platform qui vise à contenir les modèles utilisés pour construire des APIs “automatiquement” avec API Platform et qui ne sont pas des entités Doctrine

B

• Builder : service qui construit un service avec ses éléments requis ou des valeurs par défaut (c.f. Factory pour construire des objets)

C

• Client : service qui permet de se connecter à un service tiers (une API, un webservice…)
• Command : service qui exécute des scripts / des processus en ligne de commande
• Controller : service qui prend en charge une requête HTTP et fourni une réponse HTTP

D

• DataFixtures : dossier créé par le bundle Doctrine Fixtures dans lequel on vient créer ses classes “Entity1Fixture”, “Entity2Fixture” etc…
• DataManager : service qui organise, tri, filtre et/ou enrichi des données provenant d’une source tierce (similaire à la notion de DAO)

E

• Enricher : service qui enrichi une donnée ou un objet avec la donnée d’une autre source
• Entity : objet Doctrine composant le modèle de données
• EnvProcessor : contient les classes qui définissent des Environment Variable Processor custom
• EventListener : service qui met en place les processus à exécuter quand un événement écouté est déclenché
• EventSubscriber : service qui met en place les processsus à exécuter quand un évènement auquel il souscrit se déclenche
• Exception

F

• Factory : service qui construit des objets avec les requis et/ou les valeurs par défaut (assez similaire à Builder pour les services)

G

H

• Handler : service qui orchestre une logique métier, organise, tri, filtre des objets/entités (en français : “gestionnaire”)
• Helper : service qui fournie des fonctions utiles “un peu partout” et simples (souvent static)

I

• IndexManager : service qui organise, tri, filtre et enrichi des documents provenant d’un index Elasticsearch

J

K

L

M

• Message : structure de données qui permet de former une enveloppe pour faire des transiter des informations dans des files de messages
• MessageHandler : service qui organise la logique métier associé à la réception de message
• Model : objets métiers (DAO)

N

O

P

• Paginator : service qui permet de mettre en place une pagination

Q

R

• Repository : service associé aux entités Doctrine et qui contient des requêtes DQL ou SQL, ou des constructions dynamiques de requêtes (grâce aux “query builder” par exemple) et qui permet de récupérer les objets ou les tableaux d’objets répondant à ces requêtes (ces services ne contiennent pas de logique métier, qui doit plutôt être retrouvé dans les “Handlers”)

S

• Security : ce dossier contient les services spécifiques et relatifs au composant Security de symfony (ex: Authenticator, Provider…)
• Serializer : service qui procède à la sérialisation ou la dé-sérialisation d’objets données
• Service : ce dossier était beaucoup utilisé depuis l’apparition de Symfony 2 pour y mettre tout ce qui n’était pas un contrôleur ou un repository, mais il est imprécis. Sur les projets importants il devenait “fourre-tout” et dense. J’essaie au maximum de ne plus l’utiliser et de le faire disparaître au profit de tous les autres cités dans cet article

T

• Transformer : service qui converti une donnée d’un certain type dans un autre type
• Twig : extensions twig personnalisés (filters ou functions)

U

V

• Validator : service qui contrôle des règles de validation

W

X

Y

Z

Aujourd'hui je tend aussi à ajouter dans chacun de ces namespaces des sous-namespaces "métiers". Par exemple src/Entity/User/ peut contenir :

• src/Entity/User/User.php
• src/Entity/User/Group.php
• src/Entity/User/Role.php
• src/Entity/User/RequestPassword.php

Ceci permet d'éviter d'avoir une arborescence avec des dossiers dans lesquels il faut scroller vers l'infini et l'au delà...

Aidez moi à faire évoluer et vivre ce sujet !

Je me demande d'ailleurs si avec Laravel c'est plus ou moins structuré de la même manière ?