[2011–05–05] Finalizace Dependency Injection

Naopak, DI je poměrně dost složitá věc. Jako jednoduchá se zdá teprve ve chvíli, kdy ji člověk pochopí (jako ostatně vše). Proto v Nette existoval a bude existovat jak DI, tak Service Locator.

HospiLan: Díky za praktickou ukázku :-)

Takže Nette\DI\Container slouží k přístupu ke třídám, které chci mít k dispozici kdekoli v aplikaci? Jak se to potom liší od používání statických tříd?
Viz. HospiLanův příklad:

// Místo
$this->foo = $this->context->models->foo->find($id);

// můžu použít
$this->foo = Foo::find($id);

Výsledek je stejný, o načtení třídy Foo se postará RobotLoader, odpadá zbytečné vytváření MyModelsLocator a MyServiceFactories (které určitě sežerou trošku té paměti, stejně tak fakt, že díky registraci služeb naroste v paměti o něco málo i proměnná $this->context).

Neberte mě špatně, snažím se DI přijít na kloub stejně, jako jsem kdysi přišel k Nette a tím i k MVC (taky jsem v MVC neviděl výhody, a teď bez toho nemůžu žít :-) )

Během vývoje myšlení (programátora) se postupně dostaneš do fáze, kdy zjistíš, že když máš funkce ve třídě, není to nezbytně ještě objektové programování.

S tím souhlasím a věřím ti ;-)

Objevíš věci jako zapouzdřenost, polymorfizmus, …

Dobře, pořád ale nevidím konkrétní přínos použití Nette\DI\Container ve výše odkazovaném příkladě.

P.S. Nemám si na to založit vlastní vlákno třeba v Obecné diskuzi?

xxxObiWan napsal(a):

Během vývoje myšlení (programátora) se postupně dostaneš do fáze, kdy zjistíš, že když máš funkce ve třídě, není to nezbytně ještě objektové programování.

S tím souhlasím a věřím ti ;-)

Objevíš věci jako zapouzdřenost, polymorfizmus, …

Dobře, pořád ale nevidím konkrétní přínos použití Nette\DI\Container ve výše odkazovaném příkladě.

P.S. Nemám si na to založit vlastní vlákno třeba v Obecné diskuzi?

Mam jeden uplne super zasadni pripad a tim jsou unit testy :-)

Unit test nesmi (nebo by nemel, uz z jeho povahy) pristupovat do databaze…jak to udelat? V Tvem druhem pripade neresitelna situace. Pokud pouzivas DI, tak jenom nekde v configu zmenis vytvareni sluzby ‚databaseConnection‘ ze tridy Database na FakeDatabase a hotovo:-)

http://pimple-project.org/ – A simple Dependency Injection
Container for PHP 5.3

xxxObiWan napsal(a):

Takže Nette\DI\Container slouží k přístupu ke třídám, které chci mít k dispozici kdekoli v aplikaci? Jak se to potom liší od používání statických tříd?

Ne, k tomu slouží tzv. service locator, v řeči Nette třída Environment. DI\Container je naopak lokální záležitost, která tvoří objekty a předává jim přes konstruktor nebo settery závislosti.

Ahoj, po delší době si prohlížím zdrojáky a dívám se na DI, už to konečně pro mě není tajemná zkratka. Ale teprv tomu začínám rozumět. Vlastně ze zajímavosti mě zajímá tato věc:
‚Proč některé služby se vypadají takto: function createServiceSession($c){return new Session($c->httpRequest, $c->httpResponse);}‘ a některé takto createServiceApplication($c){$context= new DI\Container;$context->addService($c->...;
return new Application($context);}

Jde mi o to, proč někdy, když předávám službě jinou službu, tak jednou se předají rovnou vybrané služby a podruhé se předá kontejner s vybranými službami. Je v tom nějaký rozdíl? Případně to bude předmětem refactoringu? Hraje v tom roli to, že „objekty o kontejneru nemusí vědět“ (citace z FabPot slidu o DI).

Taky jsem se díval do createServiceUser – tam je lazy vytváření služeb přes lambda funkce. Soudím, že služby se tedy jinak lazy nevytváří (sice služba se spustí při getService, ale teď mám na mysli, když chci předat službu jako v createApplication, taky ty služby se už spustí, protože $context->addService('...',$container->s...) volá getService a spustí ji tedy). Myslím jen předání služby aniž by se spustila (jako v user přes closure), ale zařídit to rovnou v containeru a vyvyrovat se používání lambda funkcí).

Mě se tohle pojetí DI líbí, nikomu to nic nenutí. Jestli budu injectovat přes constructor, setter, nebo constuctor s kontejnerem je každýho věc a špatně není ani jedno. Třeba já injectovaní jednotlicých služeb přes konstruktor nemám rád, protože když ma člověk složitou hiearchii tříd a vzpomene si že chce nějakou další službu do toho uplně prvního předka, tak to přepisovat je děs. A to že na nic nezapomenu v tom kontejneru si můžu v konstruktoru ošetřit. Právě proto vítám nějakou volnost.

Ale měl bych dotaz proč se teď v třídě Configurator ta property container plní tak jak se plní? Nebylo by lepší pro ni mít specialní container, který by měl ty továrny na Applicaton, Router atd. v sobě a předával by se on? Asi mi tam něco uniká.

Ani napsal(a):

Třeba já injectovaní jednotlicých služeb přes konstruktor nemám rád, protože když ma člověk složitou hiearchii tříd a vzpomene si že chce nějakou další službu do toho uplně prvního předka, tak to přepisovat je děs.

Při používání DI kontejneru bys tohle přepsal právě jen na jednom místě v configu.

Říkám si, jestli je skutečně účelné, aby __set byl zkratkou pro addService(). Nevypadá tohle příliš divně?

$container->template = 'Nette\Templating\FileTemplate';
dump($container->template); // vrátí string nebo objekt FileTemplate?

$container->database = function() { return ... };
dump($container->database); // vratí objekt Closure?

Setter by měl být přímočařejší, tj. umět vkládat jen objekty samotné, nikoliv továrničky. Pak by $container->template = 'FileTemplate' vyhodil výjimku a $container->database = function() {} vložil jako službu objekt Closure.

Co myslíte?

Ty settery jsou magické, getter stačí :)

Napiš si nad to phpDoc:

/** @var MyDatabaseClass $database */
$database = $this->context->database... // or whatever

Mělo by to fungovat. Snad.

Kdysi jsem si zvykl psát tu anotaci až pod definici hodnoty proměnné, protože NetBeans si občas usmyslel, že si dokáže napovídání odvodit podle toho, co do té proměnné dávám ;).

<?php

$main = $this->getContext()->mainDibiConnection;
/** @var \DibiConnection $main */

?>

Editoval Petr Motejlek (7. 6. 2011 10:41)

Zdravím,
snažím se pochopit celkovou problematiku DI, avšak trošku jsem na vážkách, co se týče praktické části. V praxi tedy:

v boostrapu si vytvořím kontajner se všemi modely například metodou callbacků:

<?php
$container->addService("Database", function($c) { return new Connection; }
$container->addService("Users", function($c) { return new Users; }
$container->addService("Articles", function($c) { return new Articles; }
?>

následně v presenteru, když budu chtít přistupovat k těmto modelům, a ty modely jsou navázány na databázi:

<?php
public function actionDetail() {
  $this->template->articles = $this->context->Users->getLastRegisterUsers();
  $this->template->users = $this->context->Articles->getNewArticles();
}
?>

Pro příklad v duchu DI, je toto správně? V případě, že ano, jakým způsobem docílím, aby se předalo spojení do databáze daným modelům Users a Articles?

Logicky podle úvodního příspěvku by to tedy šlo takto:

<?php
$container->addService("Database", function($c) { return new Connection; }
$container->addService("Users", function($c) { return new Users($c->Database); }
$container->addService("Articles", function($c) { return new Articles($c->Database); }
?>

Avšak toto způsobí, že se vytvoří dvě instance Connection, což je očividně nežádoucí, a řešení je dle tedy slajdů v prezentaci (link viz výše), využitím statické proměnné, čili:

<?php
$container->addService("Database", function($c) {
   static $conn;
   if (is_null($conn)) $conn = new Connection;
   return $conn;
}
?>

Oproti tomu je zde namítáno, že statické třídy jsou zlo (vím toto třída není), avšak tedy jak to správně má být?

Děkuji velice za nakopnutí a utříbení myšlenek, doufám, že neplácám úplně z cesty ;(

Editoval frosty22 (14. 6. 2011 0:51)

Proč by to mělo vytvořit dvě instance Connection?

frosty22 wrote:

V tomto případě, pokud chci vytvářet nové instance modelů, tak k tomu tento kontajner určen není?

Proč by k tomu neměl být?

Editoval Jan Tvrdík (14. 6. 2011 1:35)

Jedna, proboha! Co bys asi dělal se dvěma.

@frosty22: můj ty smutku… Proč ti vadí, že budeš mít vždy právě jednu instanci svého modelu? To je naprosto v pořádku.

ActiveRecord je anti-pattern k Dependency Injection. Nejde ho s ním používat. Čili pokud máš modely jako ActiveRecord, ztrácí smysl snažit se je nacpat do Containeru.

frosty22 napsal(a):

<?php
public function actionDetail() {
  $this->template->articles = $this->context->Users->getLastRegisterUsers();
  $this->template->users = $this->context->Articles->getNewArticles();
}
?>

Pro příklad v duchu DI, je toto správně? V případě, že ano, jakým způsobem docílím, aby se předalo spojení do databáze daným modelům Users a Articles?

Tohle vůbec není DI, přístup, který zde používáš (načítání věcí z context) se nazývá ServiceLocator.

manik napsal(a):

Tohle vůbec není DI, přístup, který zde používáš (načítání věcí z context) se nazývá ServiceLocator.

A k čemu je tedy proměnná $this->context v presenteru vůbec přístupná? Jak jinak bys v presenteru použil nějakou službu?

$this->context je v Presenteru v pořádku.

A nemusíš ho dávat do Containeru. Na to je Nette\Application\PresenterFactory. Tu si můžeš implementovat vlastní a tam si právě můžeš „ještě čistěji“ vytvořit Presenter, který Container nebude potřebovat, ale dostane jen svoje služby.

frosty22 napsal(a):

$form = $this->context->appform;
$session = $this->context->session;

prostě žádné „new“ :)

Ale v tomto případě, je to alternativní logika funkčnosti doposavadního Environment.

Injectujes nejakou službu. O vytváření nových instancí se postará ta služba.

$form = $this->context->formManager->getNewForm();

Ten příspěvek od manik v 8:54 bych smazal, každýho kdo neví to jenom poplete.

Editoval Ani (14. 6. 2011 13:31)

Protože ActiveRecord je založený na získávání entit pomocí statických metod. Ty jsou tight-coupled úplně se vším už z definice.

Neříkám, že ActiveRecord je anti-pattern sám o sobě, ale navzájem se vylučuje s Dependency Injection.

Editoval HosipLan (14. 6. 2011 15:36)