Best practise Doctrine – facade, repository, service
- Petr Parolek
- Člen | 455
Ahoj,
snažím se o refactoring svého kodu a chci ho mít na úrovni.
Z internetu jsem posbíral tyto poznatky:
- repozitář pokud ho chci rozšířit o vlastní metody. Používá se jen
ke čtení dat přes metody
$this->find*,$this->createQuery()a$this->createQueryBuilder()z dané entity. Ten zaregistuju jako službu v DI a přiřadím ho v entitě:
/**
* @ORM\Entity(repositoryClass="App\Repositories\SomeRepository")
*/Vlastní repositář není povinné vytvářet, když by byl bez metod.
- službu použiju k ukládání a k úpravě dat.
Co je fasáda? Spojení s více entit pro čtení dat?
Díky za objesnění. Strejda Google mi toho moc teď neřekl okolo mých dotazů.
Editoval ppar (26. 5. 2019 18:09)
- kocourPB
- Člen | 47
Ahoj,
podla mojho nazoru a tak ako to aktualne pouzivam, ale netvrdim, ze to nemoze niekto vidiet inak :)
Repozitar (repository) – service, ktora je previazana na jednu konkretnu entitu a vsetky get*() find*() metody a pod. by mali pracovat len s touto specifickou entitou. Takze ak mam napr. UserRepository tak v nej pracujem jedine s entitou User. Metody mi vracaju len entitu User resp. pole User[] atd.
Fasada (facade) – Spaja dohromady viac potrebnych repository na zlozitejsiu business logiku, kde uz musis pracovat s viacerymi druhmi entit. Ako priklad z praxe napr. StatisticsFacade, kde si injectujem UserRepository, OrderRepository atd …
Ako vravim, je to skor moj pohlad z praxe. Ako to vidia ostatni? :)
Editoval kocourPB (28. 5. 2019 16:33)
- Andy3
- Člen | 15
Ahoj, ja treba jeste delam to, ze ORM/Entity implementuji AdapaterInterface a to obaluji Domain/Entity. Celkem se mi to vyplatilo a doprucuji si Databazove entity obalit a nevypoustet je „hole“ do aplikace. Jednak z duvodu, ze Doctrine tu nemusi byt naporad a coder by nemel mit lehky pristup ke flush();