Facade, Repository správné řešení

Tomáš Mynář
Člen | 5
+
0
-

Ahoj,

chtěl bych si připravit jádro budoucí aplikace a to tak, že Presenter vždy injectuje Facade, která injectuje a volá Repository, který obsluhuje teprve databázi. Tedy klasicky Facade nebude na přímo přistupovat k DB, ale vždy tím pověří příslušnou Repository.

BaseFacade, ze které budou všechny Facade dědit, by měla obsahovat kód, který se dle názvu pokusí příslušnou Facade najít a pověřit ji zpracováním požadavku. Pokud ji ale nenajde, pokusí se najít Repository s tímto názvem. A podobně pokud najde Facade, ale v ní nebude příslušná volaná funkce, tak ihned se koukne do Repository, jestli není až tam. Až v případě, že všechny možnosti vyčerpá, tak vyhodí error.
Tímto by odpadlo zbytečné vytváření Facade, tam kde to není potřeba a pořád by byla jednoduchá možnost Facade vytvořit a upravit jednotlivá volání, pokud bude potřeba.

Uvažuji správně a nebo je lepší injectovat vždy rovnou Repository z Presenteru pro jednoduché dotazy a pak Facade pro složitější logiku?
Případně rád uvítám nějaké vaše tipy, zkušenosti či podklady k nastudování.

Díky moc za váš čas.

vojtamares
Člen | 26
+
+3
-

Ahoj

Osobně mi to přijde trochu jako magie a časem se z toho stane black box si myslím, o kterém prostě nevím jak funguje. Navíc si myslím že ti IDE nebude napovídat, což vidím jako velké mínus. Typehinty to asi zvládnou, nějak se to ohne, ale…

Já jsem klidně pro mít facade pro ty věci, ale je fakt že někde není třeba a repository postačí. Ale to co píšeš mi nepřijde jako přehledné a budu na to koukat jako puk. Představ si že přibereš nového programátora třeba…

Začínám víc a víc koukat skrz prsty na fasády typu ArticleFacade, která klidně stojí nad ArticleRepository, ale reálně dělá všchno a je to třeba jen další abstrakce navíc, nad Repository.
Takže se snažím facády trhat na menší (looking at you Single Responsibilty Principle…) a mít tak třeba CreateArticleFacade, UpdateArticleFacade a DeleteArticleFacade, s tím že třeba některé jsou jen pro API a jiné pro frontend.

Jednotlivé třídy mají pak míň závislostí a řeší jen ten jeden jediný problém a jsou lépe čitelné a třída pak nemusí mít 300 řádků, ale třeba jen 30, takže čitelnost++.

Je to otrava to dělat, chápu, ale když se pak k tomu vrátím po čase, hned vím co to konkrétně dělá podle názvu v importovaných namespace (můžu si třeba udělat interfacy, např. ICreateFacade aby měla metodu create apod. a měl bych tak jednotné API). No a co se té rutiny týče, klidně bych si napsal nějakou CLI utilitu, která by mi ty basic struktury generovala, nevím jak to umí PHPStorm, ale s nette/php-generator určitě něco vymyslet půjde.

Tomáš Mynář
Člen | 5
+
0
-

Díky za podnět k zamyšlení. Je pravda, že časem to může přinést více komplikací než užitku. A čím více nad tím přemýšlím, tím více upouštím od svého předchozího návrhu a zdá se mi zbytečně komplikovaný.