The src folder of a Symfony project contains your business classes and forms the heart of your application.
Symfony Best Practices recommends a structure for this src/ folder and a few subfolders.
Here I offer you the results of recent years and PHP projects carried out with the Symfony framework: this is a tree structure that I was able to find in the src folders.
The list is not here to set things in stone and is not official.
The purpose of this list is to create a reference for:
- defining what types of classes and services should be found in each namespace corresponding to a subfolder of the src folder
- "finding inspiration" when you don't have a design pattern that spontaneously comes to mind.
Some come from the Symfony documentation or its best practices, others from entirely personal habits.
A
- Adapter: A service that converts one object into another (see Transformer if it's data and not an object)
- Aggregator: A service that gathers data from different sources
- ApiResource: A folder created by API Platform that contains the models used to build APIs "automatically" with API Platform and that are not Doctrine entities
B
- Builder: A service that constructs a service with its required elements or default values (see Factory for building objects)
C
- Client: A service that allows you to connect to a third-party service (an API, a web service, etc.)
- Command: A service that executes scripts/command-line processes
- Controller: A service that handles an HTTP request and provides an HTTP response
D
- DataFixtures: A folder created by the Doctrine Fixtures bundle in which you create your "Entity1Fixture", "Entity2Fixture", etc. classes
- DataManager: A service that organizes, sorts, filters, and/or enriches data from from a third-party source (similar to the concept of DAO)
E
- Enricher: Service that enriches data or an object with data from another source
- Entity: Doctrine object that makes up the data model
- EnvProcessor: Contains classes that define custom Environment Variable Processors
- EventListener: Service that sets up processes to be executed when a listened event is triggered
- EventSubscriber: Service that sets up processes to be executed when an event to which it subscribes is triggered
- Exception
F
- Factory: Service that constructs objects with required and/or default values (quite similar to Builder for services)
G
H
- Handler: Service that orchestrates business logic, organizes, sorts, and filters objects/entities (like a "manager")
- Helper: Service that provides useful "all over the place" and simple (often static) functions
I
- IndexManager: Service that organizes, sorts, filters, and enriches documents from an index Elasticsearch
J
K
L
M
- Message: Data structure that forms an envelope for transmitting information in message queues
- MessageHandler: Service that organizes the business logic associated with message reception
- Model: Business Objects (DAO)
N
O
P
- Paginator: Service that allows you to set up pagination
Q
R
- Repository: Service associated with Doctrine entities and that contains DQL or SQL queries, or dynamic query constructions (using query builders, for example) and that allows you to retrieve objects or arrays of objects that respond to these queries (these services do not contain business logic, which should instead be found in the "Handlers")
S
- Security: This folder contains services specific to and related to the Symfony Security component (e.g., Authenticator, Provider, etc.)
- Serializer: Service that serializes or deserializes data objects
- Service: Since Symfony 2 this folder was often used to store everything that wasn't a controller or repository, but it's imprecise. On large projects, it became a catch-all and dense resource. I'm trying as hard as possible to stop using it and eliminate it in favor of all the others mentioned in this article.
T
- Transformer: service that converts data of a certain type into another type
- Twig: custom Twig extensions (filters or functions)
U
V
- Validator: service that checks validation rules
W
X
Y
Z
Today, I also tend to add "business" sub-namespaces to each of these namespaces. For example, src/Entity/User/ can contain:
- src/Entity/User/User.php
- src/Entity/User/Group.php
- src/Entity/User/Role.php
- src/Entity/User/RequestPassword.php
This avoids having a tree structure with folders that require endless scrolling...
Help me keep this topic moving forward and alive!
I'm wondering if it's structured more or less the same way with Laravel?
This post is a translation of a first post in French, available here: https://dev.to/neothone/arborescence-dun-projet-php-symfony-34go
Top comments (0)