Fasáda nefasáda, operace nad vícero repozitáři

thunderbuff

Ahoj, řeším problém týkající se krásy kódu a potřeboval bych nějaké další názory :)

Ve své aplikaci (2.1 dev) využívám pro přístup k datům tenkou vrstvu pracující nad Nette\Database. Nemá žádnou hi-tech funkčnost, jen obaluje ActiveRow do konkrétních entitních tříd. Mám několik repozitářů, každý se stará o své entity. Pokud na straně front-endu potřebuji provést operace vyžadující více repozitářů, zabalím je do nějaké fasády. Návrh je pak docela čistý a kód přehledný.

Problém nastane v momentě, kdy potřebuji cronem importovat velká data do mnoha tabulek najednou. Pokud se budu držet repozitářů a fasád, kód bude sice relativně přehledný a bude mít stejnou kulturu jako front-end, ale bude paměťově náročný a pošle obrovské množství query na databázi. Rozhodl jsem se tedy vytvořit nějakou importovací třídu, která vůbec nepoužívá repozitáře a pracuje přímo s Connection a SelectionFactory. Akademicky to asi není správně, protože ta třída nerespektuje zodpovědnosti jednotlivých repozitářů a přistupuje do všech tabulek v databázi. Na druhou stranu sníží počet dotazů třeba na setinu (oproti řešení s repozitáři a fasádou) a to už docela stojí za to.

Jak byste takovou třídu pojmenovali a kam ji umístili? Není to fasáda, protože nesdružuje závislosti, ale dělá vše sama; a zároveň to není repozitář, protože se vrtá v celé databázi. Jak řešíte takové „špeky“ vy?

Šaman

Do adresáře a NS Model, ale někam zcela mimo, do import/export rutin, které budou mít asi vlastní NS a na začátku anotaci s varováním, že tohle se pro běžnou práci nemá používat. Žádný přídomek bych ji asi nedával, prostě ImportFooBar. Případně celou import/export funkcionalitu vyčlenit do samostatného modulu, pokud je to vhodné.

A co se repozitářů týče, někde není řečeno, že je to jediný správný způsob tvorby modelu. Jen má mnoho výhod (a taky pár nevýhod), kvůli kterým se často používají. Třeba, že práce s jednou tabulkou je jen v jedné třídě a aplikace je pak přehledná. Ale jakmile je potřeba optimalizovat konkrétní SQL dotazy, tak unifikovaný přístup přes repozitáře přestává být vhodný. To, že jiný modul používá jiný model není chyba, pokud víš, proč to děláš.

Editoval Šaman (6. 2. 2014 5:24)