Jsem na nervy z dokumentace

@Felix Moc bych si přál, aby jednou zmizela ze sandboxu slova „model“, „manager“ apod. Nelíbí se mi ani „service“ (byť to je dáno něčím trošku jiným).

Každý týden narazím na projekt, kde vidím adresářovou strukturu podobnou tomuto:

app/
	model/
		service/
			manager/
				bullshit/
					eventBiggerBullshit

Chápu, že pojmenování třídy podle toho, co dělá, je strašně těžké a občas úsměvné. Ale pro nováčka dává smysl a na první pohled je jasně vidět, co dělá. app/model/UserManager v namespace App\Model\UserManager mi řekne (s prominutím) velké prd. Řeší to ukládání dat uživatele? Pracuje to vůbec s DB? Cachuje to něco? OMG, ono to dědí od Nette\Security\IAuthenticator. Waat?
Vždyť by stačilo jednoduše třídu rozdělit do dvou – třeba App\Security\UserAuthenticator a App\Database\UserDataProvider. Komu z vás JE JASNÉ, co tyto třídy dělají? Všem? GOOD!

Ale třeba je to blbost a lidem to tak smysl dává, těžko soudit – je to jen můj názor. :)

@PavelJanda UserManager dělá přece všechno a ještě sám.
https://github.com/…rManager.php

Já myslim, že dokumentace je asi ok z pohledu, že ukazuje co jak dělat ve frameworku (co se dělá jinak ve srovnání s ostatními fw/spaghetti code). To že neukazuje jak vrstvit/dělat architekturu aplikací je myslim ok, protože to by zde muselo být napsáno úplně vše (takhle zapnu počítač, takhle píšu v editoru, takhle nahraju na ftp, …) úplně framework agnostic věci.
Pokud vím tak v dokumentaci je napsáno jak využívat DI kontejner, jak si předat nějakou závislosti, různé způsoby předání závislostí.

d@rkWolf: Co ti vlastně v dokumentaci přesně chybí? Jak se připojit k databázi? Jak si zaregistrovat službu (model)? Jak si předat službu do presenteru?