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
22 lines
1.2 KiB
Markdown
22 lines
1.2 KiB
Markdown
---
|
|
globs: '["src/**/*Repository.php"]'
|
|
description: Ensures minimal boilerplate by avoiding unnecessary custom
|
|
Repository classes for standard CRUD operations, while still allowing them for
|
|
complex queries.
|
|
alwaysApply: 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:
|
|
1. Complex queries involving multiple joins, subselects, or specialized search logic are required.
|
|
2. 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:
|
|
|
|
```php
|
|
$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. |