Kam správne umiestniť službu

Unlink

Zdravím

presentery umiesnujeme do zložky Presenters
modely do Models
templaty do Templates

Rád vedel, ako riešite umiestnenie služieb. Mám povedzme nejaký modul, a tento modul odosiela nejakým spôsobom maily a keďže to nechceme mať všetko v presenteroch, tak si na to spravíme službu (Triedu). Kam takúto triedu umiestniť? Myslím že by mala byť pri danom module.
Mám si vytvoriť zložku Services alebo ako podobnú situáciu riešite?

Ďakujem

Šaman

Pokud ta služba obsahuje nějakou logiku aplikace, tak to mám v modelu. Pokud je to obecná služba, kterou používám ve více aplikacích, tak jde do složky /libs, která je přímo v rootu a robotLoader ji má nastavenou aby ji procházel taky.

Unlink

No to áno
Ale situácia je takáto, mám aplikáciu ktorá spravuje rezervácie. Jeden používateľ vytvorí rezerváciu a iný (na to oprávnený) ju môže potvrdiť.

Teraz to chcem rozšíriť o emaily. Pri vytvorení rezervácie sa pošle email všetkým zodpovedným osobám a následne pri potvrdení / zamietnutí sa pošle email autorovi rezervácie.

Chcel by som si na to spraviť službu, táto služba bude potrebovať Mailer, LatteFactory (aby som mohol renderovať obsah toho emailu zo šablóny) a presenter?
Pretože mám ešte staršie nette takže si na tvorbu linkov nemôžem injektnúť link factory.

A nejako sa mi nepozdáva, že trieda s takýmito závislosťami by mala byť medzi modelmi.
Idem na to dobre, alebo by sa to celé malo riešiť inak?
Ďakujem.

Azathoth

Veškerá logika aplikace má být v namespace/složce model. Pokud z toho nechceš mít knihovnu. Takže ve tvém případě rozhodně model, já, a myslím, že asi všichni, máme veškeré Services v modelu.

Šaman

Případně si ten emailer vytvoř jako komponentu (může být nevizuální).

Michal Vyšinský

Model je prakticky veškerý kód aplikace. Model není nic konkrétního a může pracovat s čímkoliv, databáze, queues, soubory…

Prakticky můžeš použít rozdělení třeba takto:

app/Presenters
app/Mailer
app/Bookings

atd.

prakticky ti rozdělení do modelu přidá jednu složku navíc ale nic tím nezískáš

Editoval Michal Vyšinský (13. 4. 2015 16:20)

Oli

Podle mě to je na tobě. Já to mám například tak, že pokud vytvářím komponentu (třídu, která dědí z UI\Control), tak to mám v app/components. Jinak většsinou v app/model, jako asi většina tady…

Důležité je aby jsi v tom měl nějaký systém a vyznal se v tom.

Unlink

Okej, ďakujem za usmernenia, ja som totižto „Model“ bral ako tú vrstvu, ktorá odráža logiku databázy.

Šaman

Já si to myslel. Zjednodušeně se dá říct, že model je všechno, co zůstane, pokud stejnou aplikaci budeš chtít provozovat jako web, jako desktopovou aplikaci i jako konzolovou aplikaci ovládanou z příkazové řádky.
Změní se jen způsob prezentování (třeba terminálová aplikace ovládaná přes telnet bude mít úplně jinak řešené prezentování formulářů), ale třeba definice formuláře, validační pravidla polí a zpracování formuláře zůstává stejné (třeba pole email musí mít ve všech třech podobách aplikace stejný formát a ve všech aplikacích se na něj má odesílat stejná zpráva).

Tohle je už trochu extrémní příklad, ale pro oproštění od představy, že model === data access objects je dobrý. V reálu dochází ke kompromisům, takže model občas něco ví o existenci presenteru, ale v ideálním (a nejlépe testovatelném) případě opravdu emailer netuší kdo a proč ho bude volat, jestli klasická Nette aplikace, nebo nějaký standalone script spouštěný CRONem. Jestli má jasně stanovené vstupy (ideláně rozhraní), tak si ho může zavolat kdokoliv odkudkoliv.

Editoval Šaman (13. 4. 2015 17:47)