jens
98f4e126fc
PHP Unit Tests / test (push) Has been cancelled
- Add PersonEntity in Data layer with Doctrine ORM attributes - Add PersonModel in Logic layer for business logic - Add immutable PersonDto in Shared layer - Configure doctrine/orm dependency in composer.json - Add Doctrine deprecation triggers to phpunit configuration
1.2 KiB
1.2 KiB
globs, description, alwaysApply
| globs | description | alwaysApply |
|---|---|---|
| ["src/**/*Repository.php"] | Ensures minimal boilerplate by avoiding unnecessary custom Repository classes for standard CRUD operations, while still allowing them for complex queries. | true |
In Symfony and Doctrine based applications, avoid creating custom Repository classes for simple CRUD or standard query operations (e.g., findOneBy, findBy). Instead, use Doctrine's native EntityRepository directly via $entityManager->getRepository(Entity::class) within the Provider or Processor implementations.
Only create a custom repository when:
- Complex queries involving multiple joins, subselects, or specialized search logic are required.
- Query logic is reused across multiple Providers/Processors and warrants encapsulation for DRY compliance.
When no custom repository is needed, Inject EntityManagerInterface directly into the Provider or Processor and fetch the repository inline as shown below:
$repository = $this->entityManager->getRepository(EntityClass::class);
$result = $repository->findOneBy(['id' => $id]);
Do not create an empty or wrapper Repository class that only delegates to Doctrine's native methods.