Architektura, která roste s vaším projektem
Architektura, která roste s vaším projektem

Jedna z nejčastějších výzev při vývoji PHP aplikací je správná organizace kódu. Kam umístit presentery? Kde by měly být jednotlivé třídy? A jak zajistit, aby struktura projektu rostla přirozeně s jeho vývojem?
Dokumentace Nette přináší komplexního průvodce adresářovou strukturou, který nabízí odpovědi na všechny tyto otázky.
Kvalita organizace kódu zásadně ovlivňuje jeho srozumitelnost. Při
prvním pohledu na nový projekt byste měli rychle pochopit jeho účel.
Podívejte se na tento adresář app/Model/
:
app/Model/
├── Services/
├── Repositories/
└── Entities/
Co vám tato struktura prozradí o aplikaci? Téměř nic. Srovnejte s alternativou:
app/Model/
├── Cart/
├── Payment/
├── Order/
└── Product/
Na první pohled je jasné, že jde o e-shop. V tom spočívá síla doménově orientované struktury, kterou dokument představuje.
Průvodce také ukazuje, jak strukturu přirozeně rozvíjet s růstem projektu. Ať už začínáte nový projekt nebo chcete vylepšit existující aplikaci, najdete zde principy pro informovaná rozhodnutí o organizaci kódu.
Přečtěte si kapitolu Adresářová struktura aplikace v dokumentaci Nette a starší blogpost Elegantnější strukturování presenterů.
Další čtení
- Elegantnější strukturování presenterů
- S novou dokumentací Nette Database píšete bezpečnější kód
- Ako predávať adresáre projektu registrovaným službám
- Nette Vite – použití Nette s Vite pro rychlý lokální vývoj
- Jedna řádka v konfiguraci zrychlí vaši Nette aplikaci. Jak je to možné?
- Jak šel čas s webem nette.org 🕒
Komentáře
V nette je to o to tezsi protoze se muze slozkovat jak chce. Takze si pak clovek udela peknej mrdnik kterej pak 1000× predelava a porad nemuze docilit systemu. Osobne ale namam rad moc slozek, kdyz pak neco delam tak se proklikavat k naky tride je mega vopruz.
„Složkovat“ se dá v jakémkoliv frameworku.
Mě naopak přijde, že hodně složek často vede spíš k nepřehlednosti. Nějaký základ je dobrý, ale třeba rozdělit si model na Entity a Enum beru jako dobré. Další štěpení na Entity/XY, AB, EF … atd. mi přijde spíš jako obsese :D. Ze zkušenosti, to pak často vedlo k podivné názvové konvenci, protože to vlastně umožnilo dát do více složek víc stejných názvů a pak to ztrácelo na přehlednosti.
Ale nakonec, ať se každý soudruh rozhodne podle preferencí :D.
Chcete-li odeslat komentář, přihlaste se