Dependency injection si razí cestu do 2

Takže jestli to chápu, tak je to vlastně ContextServiceContainer. Kontejner se službama v kontextu k danýmu objektu? Zatímco jen ServiceContainer by byl jakoby „globální“?

Proč by nemohlo? Nevím, jak jsou na tom PHP IDE s namespaces, ale třeba v Javě mi Eclipse nabízí třídy z různých packages (i když asi prioritně nabízí importované třídy apod.) a při zvolení mi přidá import (něco jako use), je-li potřeba, popřípadě doplní na fully-qualified verzi, nejde-li jinak. (V Javě nejsou aliasy, takže v případě používání dvou tříd se stejným názvem v jednom souboru musí být alespoň jedna fully-qualified.)

EDIT: malá editace

Editoval v6ak (18. 9. 2010 14:41)

Tohle je spís argument proti Container, ne?

Půjde hodit parametrem konstruktoru služby nějaká jiná služba? (jak to předváděl Fabien na workshopu Symfony)

Taky by tomu Contextu/ServiceContaineru/… slušel ArrayAccess.

Další věc je, že v komponentách a presenterech není metoda na získání kontextu, ale to je předpokládám dočasná záležitost.

@pekelnik Nebo by ty gettery mohly fungovat podobně, jako princip továrniček v komponentách (kdyby při volání getRouter() ještě router neexistoval, automaticky by se zavolala createServiceRouter()). Nebo je to moc velká magie?

@martin: to co popisuješ se dělá takhle:

<?php
$context->addService('foo', function () {
	return new FooService();
});
?>

@paranoiq: myslím že to bylo myšleno tak že v presenteru není ani zmínka o $contextu a já se přidávám k tomu „Zatím“ :)

Editoval pekelnik (29. 9. 2010 15:58)

paranoiq napsal(a):

Honza Marek napsal(a):
Další věc je, že v komponentách a presenterech není metoda na získání kontextu, ale to je předpokládám dočasná záležitost.

já předpokládám, že to je záměr. context by sis neměl sám brát, měl bys ho dostat. jakmile by sis třídou pro kontext někam šahal bylo by to porušení principu DI

A kudy bych ho měl dostat třeba do toho presenteru?

Jo a nedělá to. O to mi jde.

Nemám s tím praktickou zkušenost a tedy netuším, jaké to má plusy a mínusy. Ale klidně zkus vytvořit prototyp a demonstrovat ho.

jinak tady je pěkně popsaná ta dependency injection ze symfony… taky bych byl pro, aby se použila…

Je pravda, že tady mě nenapadá lepší řešení než tam hodit nějaký Context/Container. Snad je někdo chytřejší než já :) Nicméně alespoň by konstruktor měl brát interface a ne přímo Nette\Context.

mkoubik napsal(a):

Mám hodně odvážnej návrh, co takhle dát do Nette\Object (nebo nějakého potomka – to si můžu implementovat sám) setContenx(Nette\IContext $context), aby se tím zbytečně neza*íraly konstruktory těch tříd, kde někdo uznal, že v nich bude Context potřeba.

ne

Ono nemusí jít nutně o setter, může to být i konstruktorem, rozdíl je v tom, že se předávají přímo konkrétní objekty a ne jakýsi kontejner, takže třída nemusí o automatickém DI vůbec vědět. Mohlo by to například vypadat takhle:

class Model extends Object
{
	private $logger;

	public function __construct(ILogger $logger) {
		$this->logger = $logger;
	}

	public function doSomething() {
		$this->logger->logSomething();
		...
	}
}

v testu můžeš použít přímo new a předat ILogger konstruktorem/setterem, ale klasické IoC kontejnery fungují tak, že z nějaké konfigurace/anotací načtou strom závislostí a když požádáš o Model, tak podle toho vytvoří instanci/použijí existující a předají mu konkrétní implementace všech jeho závislostí.

Výhodou je variabilita – můžou nastat např. tyto situace:

• Všechny objekty používající ILogger používají stejnou instanci (singleton + jen jedna implementace)
• Objekty používající konkrétní implementaci DatabaseLogger používají stejnou instanci (singleton)
• Každý objekt závislý na DatabaseLogger má vlastní instanci
• Existují např. 3 různé instance DatabaseLoggeru lišící se závislostmi/nastavením a každá je používána určitou skupinou objektů

to už závisí na kontejneru a konfiguraci, přitom samotné business třídy vypadají jakoby se nechumelilo (až např. na anotace) a skládal si je programátor ručně.

Existuje i tzv. autowiring, kdy nic nenastavuješ a když požádáš o IModel, tak se kontejner pokusí najít třídu, která ho implementuje, vytvoří její instanci, předá jí podobným způsobem implementaci ILogger atd, ale to už je docela magie.

Doporučuju nastudovat Spring Framework, nebo třeba JavaBeans.

Ještě dodám že chápu výhody stávájícího řešení (pomocí __get($name) v contextu se dají závislosti vytvářet „líně“ v továrničkách), třídy frameworku to klidně můžou používat, ale pro vlastní třídy (především modelovou vrstvu) by se nějaké „true IoC“ hodilo. Mimochodem Nette\Context by se mohl taky předávat tímto způsobem, když by to tam už bylo.

Editoval mkoubik (6. 10. 2010 16:55)

Me se to libi. Z RobotLoader by slo vytahnout kdo implementuje jake rozhrani a zadna konfigurace by nebyla nutna. Jen v pripade, ze by bylo vic moznosti tak by to hodilo vyjimku a pozadovalo konfiguraci. Jinak by to mohlo fungovat „magicky“.

Jediny problem vidim v tom, ze vsechny objekty by se museli vytvorit pred predanim do konstruktoru. Coz by slo obejit predanim tovaren a definovat pozadovane interface napr pomoci anotace. Skoro by se mozna vyplatilo predat rovnou ten Nette\Context, ale osobne bych rad, aby objekt vubec nemusel byt na Nette\Context vazany a ani o nem nevedel.

Schudnou cestou by bylo aby samotne vytvoreni objektu bylo co nejmene narocne a kazdy objekt si resil sam svoje lazy loading. Tusim ze tu David zminoval napr inicializaci zurnalu. Hold o lazy inicializaci by se musel postarat sam objekt Jurnal.

Tovarnou jsem myslel neco co vrati existujici tridu nebo vytvori novou.

Napr:

function factoryXXX() {
	static $ins;
	if (!$ins) $ins = new XXX();
	return $ins;
}

Tak vlakno som precital parkrat a kontrolujem ho denne na nove prispevky, no stale mam par nezrovnalosti. Taktiez som si musel objasnit pojem dependency injection intuitivne som vedel o co go, ale chcel som aj trochu teoreticky BG.

Z uvedeneho hlasujem pre context, aj ked je to v podstate uz asi zbytocne.

Skor by ma zaujimalo:

• ako bude rozlisitelne, ktore veci dany objekt potrebuje a teda co sa ma injektovat v kontexte? Alebo do kazdeho objektu predavat kompletny kontext?? Nebude to mat vplyv na vykon?
• rozmanitost injektovanych sluzieb je samozrejma obmedzovana len kreativou programatorov, ako sa dosiahne nejake rozumne inicializovanie sluzieb a ich nastavovanie?
• bude k tomu v konecnom dosledku dostupna poriadna dokumentacia, priklady? Podla mna sa jedna o celkom velky posun vo filozofii ako pisat veci v Nette (David sice pise, ze Nette obdobne funguje v podstate od zaciatku ale zaroven spomina, ze sa vzdy preferoval iny pristup k sluzbam) a preto by si zasluzil aj poriadne intro.

westrem napsal(a):

• ako bude rozlisitelne, ktore veci dany objekt potrebuje a teda co sa ma injektovat v kontexte? Alebo do kazdeho objektu predavat kompletny kontext?? Nebude to mat vplyv na vykon?

Z principu věci ne. Protože objekty jsou v PHP standardně předávány jako reference. Tj. jediné co „zaberou“ je přidání dalšího ukazatele do paměti což je nula nula nic.

• bude k tomu v konecnom dosledku dostupna poriadna dokumentacia, priklady? Podla mna sa jedna o celkom velky posun vo filozofii ako pisat veci v Nette (David sice pise, ze Nette obdobne funguje v podstate od zaciatku ale zaroven spomina, ze sa vzdy preferoval iny pristup k sluzbam) a preto by si zasluzil aj poriadne intro.

Bude! Ostatně jako k celému Nette 2.0

Pokud si dobře vzpomínám, tak byla řeč o klonování Contextu. A to IMHO nebude až tak časté, aby to mělo významný vliv.

Brrrrr, Context je imho stejně špatný, jako Manager.

Jedná se o kontext čeho? InjectionContext? Proč ne třeba Injector. Líbí se mi i Provider a Container. Evokuje to ve mě, že mi něco předá, že pro mě má nějaká data. Kdežto kontext si prostě neumím dát do kontextu. :)

Trochu mi to přijde jako krok zpět :)
viz přednáška „Jaro 2008:http://www.avc-cvut.cz/avc.php?… 18minut
slide
Nový název pro "controller“
Příliš mnoho con…

• Control
• Controller
• FrontController
• Container, COmponent, COnfig, Collection, COrnflakes