sandbox: nette + dibi + model loader

Mám chuť ti to smazat. ModelLoader je považován za odpornou zastaralou praktiku, porušující všechny pravidla pro psaní čistého kódu.

Pokud bude xlilien souhlasit s úpravou sandboxu na rozumnější formu, tak rád pomůžu.

První věci co jsem si všiml:

1. Předání závislostí do modelů
2. Předávání závislostí do presenterů
3. Zbavení se contextu

(Chci se odvděčit komunitě kolem Nette za skvělou, ovšem na přispívání do nette/nette se zatím necítím)

Filip Procházka wrote: ModelLoader je považován za odpornou zastaralou praktiku, porušující všechny pravidla pro psaní čistého kódu.

Mýlíš se, můj drahý HosipLane. Neporušuje to zdaleka všechna pravidla pro psaní čistého kódu, spíš tak jedno či dvě. Není to odporná praktika, ale funkční přístup nasazený v mnoha aplikacích (po celém světe, napříč programovacími jazyky) disponující určitými nedostatky kvůli kterým je dnes často (ne vždy!) preferováno DI. (Nedíval jsem se na konkrétní implementaci.)

Jan Tvrdík napsal(a):

Není to odporná praktika, ale funkční přístup nasazený v mnoha aplikacích (po celém světe, napříč programovacími jazyky) disponující určitými nedostatky kvůli kterým je dnes často (ne vždy!) preferováno DI.

Mám pochopení pro service locator v presenterech. Nemám pochopení pro service locator v modelech a už vůbec nechápu, proč ho hájíš.

xlilien napsal(a):

bohužel jsem z toho nevyčetl, jak používat modely, aniž bych je všechny ručně musel registrovat v configu. Jde to?

Ano jde, pokud si napíšeš něco, co ti je všechny zaregistruje. Ale nedělej to, je to odporná magie, která vede k problémům. Prostě je všechny vyjmenuj – ano, ručně!

Jako bonus tvoje implementace by mohla být horší už jen pokud bys to celé měl statické.

1. předáváš úplně všem třídám bez rozdílu DI Container a degraduješ ho tím na podřadný service locator
2. vždy vracíš novou instanci „modelu“

Dál to nemám chuť studovat.

• Seriál Jak na Dependency Injection – Zdroják
• Dependency Injection
• Konfigurace prostředí
• Inject Autowire
• Inject a DIC továrničky

A jako bonus hračka na usnadnění předávání závislostí do presenteru

Jak jsem již řekl. V určitých situacích je service locator šikovný. Do modelu však nepatří, ani kdyby byl 100× pozlacený.

Schmutzka napsal(a):

Taky jsem s tím měl vnitřní (lenostní) problém…

Je to hodně pohodlné, např. pokud je potřeba modely měnit. Změníš na jednom místě (a navíc naprosto logicky v configu) a automaticky Ti funguje celá aplikace pod novým modelem (modely na stejném rozhraní).

V konstruktoru jej budeš standardně vyžadovat

class Foo extends Nette\Object
{
	private $bar;

	public function __construct(Bar $bar)
	{
		$this->bar = $bar;
	}

}

Njn, dalsi fail. Je naprosto standardni situace, je jeden model/manažer/fasáda vyžaduje více jiných manažerů, a že tato závislost je pouze v 1/n případů (metod). Ať už konstruktorem, tak injectem se vytvoří všechny instance manažerů. Tomu říkám optimalizační přístup. Přesně tady boduje ServisLocator, a přesně tady by se hodil Hosiplanuv autowire. Protože ten simuluje chování ServisLocatoru, ale přitom zachovává rozhraní plně podporují DI.

Dále bych se pokusil udělat toto:

1. zprovoznit přihlašování, aby také pracovalo s dibi
2. sjednotit styl (zatím jsem se snažil zachovat Tvůj @xlilien) na Nette code-styles?
3. další nápady, co by bylo v dibi-examplu dobré uvést, aby to pomohlo začátečníkům?

@grody: 3. Např. zmiňované použití modelu v jiném modelu, ale vidím problém v tom, že se musí naplnit i konstruktor BaseModelu (to je sice možné, ale nepohodlné, zejména má-li více prvků).

Taky bych zachoval BaseModel, zkus si vytvořit 5 různých modelů a do každého pěkně dostat findById().

@hrach: To zní moc dobře. Lze tedy nějak použít inject, resp. autowire service locator přímo na tyto modely?

Editoval Schmutzka (1. 1. 2013 10:21)