Ideální adresářová struktura při použití Nette

No ono vymysliet vertikalne a horizontalne skalovanie app nie je uplne sranda. V podstate pouzivam (alebo to tak vacsinou dopadne) podobnu strukturu. Co mi vsak bije do oci su zlozky models.
Ja mam na toto nazor ze model je len jeden :). To co vidim u teba je jasny priklad model == tabulka v DB (mozno to tak nie je no silne to evokuje ten pocit).

No a ked uz mam model vyrieseny tak su u mna Presentery, Komponenty, Formy … len vrstva UI. Nic viac nic menej.

No a na koniec stale zalezi na pouziti danej app lebo ani tvoje delenie nebude silver bullet. S tym sa treba zmierit.

Myslím, že je každému jasné, že ten který přístup má něco do sebe a záleží na konkrétním zadání, podle kterého se bude vymýšlet (pozor – nejen) adresářová struktura.

Jelikož byly zmíněné spíše plusy rozdělení kódu podle obsahové části projektu, zkusím vznést nějaké námitky proti. Opět připomínám, že to mohou být argumenty jen k některému zadání.

1. Admin x Front

Toto rozdělení se hodí presně tam, kde zákazník nepožaduje inline editaci, kde je jiný autenticator, uživatel má vlastní session, nastupuje dynamické ACL pro správu obsahu, a tak dále. Tedy místo, kde třeba nebudeme používat nástroje pro resizování obrázků, translator, Admin\BasePresenter bude vykreslovat komponentu nabídky.

Ještě k tomu ACL: Nezáleží na modulech, jaká oprávnění bude uživatel mít. Já si rád definuji permissions anotací presenterů/akcí a ošetřuje mi to \BasePresenter. MOduly s tím přeci nesouvisí.

2. Úplně se mi nezdá, že by někde mezi Presentery vznikaly „dlouhé dědičné linie“. Naopak se mi to jeví velice přehledné. Front\Base bude mít translator, Admin\Base ponese nějaké admin komponenty. Samozřejmě, jen a pouze v popisovaném modelu aplikace.
3. Poslední argument – podlé mého s největší vahou. Často se setkávám s tím, že v administraci je stejný formulář jako na frontu. Jedná se o modelovou situaci, může to být stejně tak komponenta pro login, nebo tisíc dalších věcí, které se použijí na více místech. Podle hesla „DRY“ si vytvoříme továrničky na komponenty/formuláře. Ty budeme muset ale stejně skladovat na nějakém supermístě NAD zanořenou adresářovou strukturou. Tedy App\Components. A rázem máme vedle sebe Komponenty, Produkt, Kategorii, Formuláře,… A to mi začíná zavánět.

---- tlustá čára ----

Abych shrnul svůj tok myšlenek: Rozdělení aplikace podle „business modelů“ je rozhodně správný krok, ale přesně v okamžiku, kdy se jedná o business logiku. Tedy modelovou vrstvu.
Nedal bych tedy všechny entity do namespace App\Entity, ale produkt do App\Category\(Product) a kategorii třeba do App\Category\(Category).

Presentery a jejich šablony naproti modelům nezastupují business logiku aplikace.

Podle me je nejdulezitejsi mit adresarovou strukturu tak aby v ni kazdy nasel to co hleda tam kde to ocekava. Tak mame ve slozce app slozky presenters, templates, controls, tak jako asi ve vetsine aplikaci postavenych na nette. Respektive mame moduly Front, Admin a dalsi, takze presentery a sablony jsou az v nich. Kazdy ten modul vypada od zakladu jinak, pouzivaji ho jini lide, prijde mi to tak prehledne. Slozka model pak reprezentuje bussiness logiku, takze se dale deli do slozek products, orders, atd.

V soucasne dobe se ale snazime nejakym zpusobem ty casti rozdelit. Nemyslim si ze pouze jina adresarova struktura by tomu pomohla. Cilem je mit napriklad pro praci s produkty samostatnou aplikaci, ktera ma vlastni bootstrap, vlastni konfiguraci a je dostupna pres nejake API – je to jeste o krok dal nez co navrhujes. Pak muze bezet oddelene od ostatnich modulu, muze se o ni starat samostatny tym a kod je mensi a jednodussi.

Hele já pořád rozděluju app na FrontModule, AdminModule atd. Přijde mi to takto nejlogičtější. Ale ostatní věci (samotnou logiku) jsem začal úplně od aplikace oddělovat třeba do libs, resp. klidně externě a přes Composer natáhnout. Podstatné je, že každé takové oddělení má svojí extension. Hrozně dobře se s tím pracuje (i když je to více psaní). Nemám potom vůbec něco jako model v app, ale mám v libs třeba Users, kde je všechno s tím související. Tzn. od entit, přes třídy s business logikou (včetně implementace IAuthenticator), různé query třídy, commandy, extension + configy kde mohu služby registrovat atd. Celou tuto část pak registruji pouze v hlavním configu a hotovo (+ možno použít i v jiném projektu).