Struktůra aplikace, kde řešit aplikační logiku

lukas.jenicek

Dobrý den

měl bych dotaz, který tu určitě byl zodpovězen asi milionkrát jde mi o to, že jsem dostal tak ze čtvrtiny hotový projekt a potřebuju tam přidávat nové funkce. Nakonec to skončilo, že jsem zjistil, že verze NETTE je dost zastaralá takže se to snažím v podstatě přepsat a využívat nejnovějších možností NETTE verze 2.2. Zatím to mám rozdělené tak, že mám ENTITY-REPOSITORY-MAPPER pattern, kde Repozitář má vždy svůj mapper, který teda bere data odkudkoliv s tím, že repozitáři je to úplně jedno. To funguje dobře ke komunikaci s databází a jinýma DATA-SOURCE, ale teď mi jde spíš kam situovat aplikační logiku. Bývalý programátor si většinou vytvořil komponentu ve které měl teda vytvořený formulář a pak v metodě ONSUCCESS vyřešil celou tuto logiku nakonec se dostal k tomu, že metoda měla asi 150 řádků a v tom se nedá vyznat podle mě je to strašlivá prasárna. A jde mi o to kde tuto logiku řešit popřípadě jak to řešíte vy. Mám prostě formulář kde po úspěšném odeslání musím řešit hodně záležitostí takže jsem si udělal složku LIBS, kde si píšu svoje vlastní třídy a ty jsem právě instancoval ONSUCCESS a vlastně zase řešil logiku aplikace v této metodě. Četl jsem o takzvané FACADE, která by měla přijímat jenom data z formuláře a pak řešit všechno a presenteru vrátit jenom odpověď. Takže otázka je taková kde a jak řešíte logiku aplikace neptám se na komunikaci s databází. Předem děkuji za jakoukoliv odpověď. Chápu, že jsem to napsal dost chaoticky, ale doufám že někdo porozumí mému problému a poradí. Předem díky

mystik

Pokud jde o jednoduší věci (nějaké drobnosti dělané při editaci záznamu, výpočet hodnot, ..) tak to patří do repository nebo entity. Na složitější věci a věci co mají závislosti se vytvářejí služby (service). Service je třída, která má jako závislosti repository a další služby (např. mailer). Komponenta pak jen zavolá metodu v service, kterou má jako závislost, a zpracuje výsledek.

V zásadě to je to čemu říkáš Facade, ale čistá facade by neměla dělat žádnou činnost jen zjednodušovat rozhraní věcí, které obaluje (tedy nic sama nedělat jen příslušně delegovat na ostatní). Facade tam můžeš mít ještě nad službama.

Editoval mystik (21. 7. 2014 14:37)

lukas.jenicek

Díky za odpověď. Já myslel, že entita je jenom obálka nad datama v podstatě jedna entita reprezentuje jeden řádek v databázi s tím, že její hodnoty naplňuju a dostávám pomocí SETTERU/GETTERU. Takže jediné co v entitě řeším je, že v SETTERU kontroluju hodnotu, kterou jí dávám jestli je to integer, určitá entita atd ..

Šaman

Může a nemusí. Tak, jak ji popisuješ ty, je to jen o něco chytřejší pole, vpodstatě si vystačíš s Row, které vrací NDatabase\Table. Když se to s „chytrostí“ entity nepřežene, tak se do ní dá předat poměrně dost logiky.

Rozhodně do entity patří všechny interní výpočty (v databázi máme u kružnice jen poloměr, ale entita nám dokáže vrátit i vypočtený obvod, obsah, resp. cokoliv, k čemu jí stačí její interní data).

Sporně se dá na entitu přesunout i část vazební logiky, tedy věci, ke kterým potřebuje repository, mapper, nebo připojení k databázi. Jestli v entitách nemáš jasno a nemáš s nimi praxi, tak se tohle nedoporučuje, ale rozhodně to nemusí být takové zlo, jak se rádo tvrdí (ale může, v tom je ten problém). :)

Entita může být i aktivní, takže umí třeba posílat emaily, pokud jí předáš nějaký mailer. Opět se takovéhle věci do entity nedoporučují dávat, pokud nevíš, že to opravdu chceš a víš proč.

Editoval Šaman (21. 7. 2014 20:12)