Best practise Doctrine – facade, repository, service

Petr Parolek
Člen | 455
+
0
-

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
+
+4
-

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)

Petr Parolek
Člen | 455
+
+2
-

Ahoj,

takhle jsem to pojmul u refacoringu kodu

Andy3
Člen | 15
+
0
-

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();