Facade, Repository správné řešení
- Tomáš Mynář
- Člen | 5
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
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
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ý.