Dependency injection === boilerplate?

Ja s oblibou pouzivam https://github.com/Kdyby/Autowired

fooProxy: FooProxy(@container::callable(@Foo))

To mi přijde zbytečně komplikované. Nette podporuje accessor stejným způsobem jako factory. Jen napíšeš interface s get() metodou (to je jediný rozdíl od factory, která má create()) a zaregistruješ jako službu

Mame potom triedu, ktora vie vratit lubovolny repozitar (vracia len repozitare). ale je to redukcia na service locator 😑

To mi zní jako nějaký lazy manager. Dokud je to konfigurovatelné z vnější, tedy do něj přidáváš páry požadovaná třída ⇒ vracená služba v konfiguraci, tak principy IoC nenarušuješ. Samo o sobě přímé volání DIC nevadí, factories a accessories jsou založené na stejném principu

Redukciou na @inject anotaciu z inject* metod neusetris nic, akurat si zadelas na problem, ked ti programator niekde v zanorenej komponente v komponente siahne na public atribut prezenteru $this->getPresenter()->foo->doStuff() a potom tu komponentu pouzijes niekde v inom prezenteri, kde nie je… a jejda!

Nebo ti property změní na public a máš tentýž problém. Od toho je code review a statická analýza – pokud v komponentě getPresenter() nepřetížíš, aby typehint obsahoval konkrétní třídu presenteru, tak tě například phpstan seřve.

Namiesto toho mi napadla moznost pretazit Presenter::tryCall a skusit vyrobit method injection po vzore Laravelu. Ma s tym niekto skusenosti alebo na to nejaky nazor?

To zní užitečně pro action/render metody, ušetříš tím accessory. Naimplementovat se to dá, otázkou je jak bys pak kombinoval parametry, které ti Nette do metody vkládá z http requestu a jak by se to dalo z vnější konfigurovat.

Ale vhladom na to, ze vytvaranie komponenty sa iniciuje v sablonach {control foo}

Nebo když se požadavek na komponentu vyskytne v http requestu, třeba při zpracování formuláře. To pak Nette komponentu vytvoří hned po zavolání action metody. V podstatě se komponenta může vytvořit v kterýkoli okamžik běhu presenteru

Ja s oblibou pouzivam https://github.com/Kdyby/Autowired

Zdánlivě narušuje zapouzdření, jde o service locator a není lazy. Předpokládám, že o chybějících službách se při kompilaci též nedozvíš a na chybu dojde až při vytvoření presenteru.

Editoval Mabar (9. 5. 2020 12:03)

Ok, co trebars toto:

// MyPresenter.php
    protected function createComponentMyForm()
    {
        return $this->wire(
            MyServiceInterface::class,
            MyOtherServiceInterface::class
        )(function (
            MyServiceInterface $a,
            MyOtherServiceInterface $b
        ) {
            return MyFormFactory::populate(new Form(), $a, $b, $this->localDependency);
        });
    }

Ak nie je zrejma ta syntax, tak $this->wire( deps )( callable ) je mozne nahradit za $this->wire( deps )->call( callable ), jedna sa o draft.

Nez sa pustime do debaty DI vs Service lokator, uvedme, naco nam vlastne DI je po praktickej stranke. Aby sme mohli casti kodu izolovat a napriklad testovat. Vyssie uvedeny staticky populator je mozne perfektne izolovat, nema ziadne zavislosti okrem tych, co mu dame vo volani.

Dalsia namietka urcite bude voci tomu, ze sa presuva miesto, kde sa zavislosti drotuju, z konfiguracie do prezenteru. Ale preco nie? Aka je „cista“ alternativa so zachovanim lazy loadingu? Vyrobim rozhranie na tovarnicku MyFormFactoryAccessorInterface a necham, nech mi ho implementuje DIC. Accessor si potom injektujem do prezenteru a v metode createComponentMyForm resolvujem tovaren, ktora mi zostavi alebo naplni formular.

$this->myFormFactory->get()->populate(new Form());

Realne instancovanie zavislosti nastane pri volani metody accessoru get a type-hintovanie v konstruktore tovarne nam zabezpeci, ze mame spravny typ. Pokial chceme nadrotovat nieco, co nie je autowired, spravime to rucne v konfiguraku.

🤷‍♂️

Tento navrh je zobecnenim patternu, ktory pouzivam na vytvaranie formularov (kde sa drotuju tie iste sluzby dookola), tam su vsak sluzby nadratovane v kontajneri „cistou“ formou.

Kod tohoto mechanizmu je tu: https://github.com/…ireGenie.php a zakomponovanie do nette (napr. bazovy prezenter) vyzera napr. takto:

abstract class BasePresenter extends Nette\Application\UI\Presenter
{
    /** @var WireGenie */
    protected $wireGenie;

    public function injectWireGenie(Nette\DI\Container $ndic): void
    {
        $this->wireGenie = new WireGenie(new Contributte\Psr11\Container($ndic));
    }

    protected function wire(...$args): callable
    {
        return $this->wireGenie->provide(...$args);
    }
}

Obmedzenie platnosti len na urcite sluzby je mozne, staci do WireGenie poslat spravne nakonfigurovany kontajner.
Nevyhodou je zrejma absencia autowiringu.

Edit: upraveny odkaz

Editoval xr (11. 5. 2020 14:57)

Urcite to je service locator, z pohladu prezenteru.

Z pohladu tovarne/populatoru formu mas vsetky zavislosti zvonka, konfigurujes/dratujes to v createComponentMyForm metode, o ktorej tovaren/populator nic nevie.
Samozrejme sa o problemoch s nepritomnostou sluzby dozvies az v momente dratovania.

Na druhej strane ti odpadnu mraky balastu a samotnu tovaren/populator mozes velmi jednoducho testovat.

Oproti $container->getByType je rozdiel v tom, ze ak chces, mozes si obmedzit rozsah dostupnych sluzieb medziclankom, nemusis pouzivat cely kontajner, ale pouzijes to, co nazyvas vyssie „lazy manazer“. Zalezi, ako si implementujes wire() metodu.

IMHO

• ❔ zachovanie IoC otazne (zalezi na uhle pohladu)
• ➕ vyhodou je mala pracnost riesenia
• ➕ a velmi jednoduche a prehladne na pochopenie
• ➕ moznost konfiguracie existuje
• ➕ testovatelnost je jednoduchsia ako v priapde tovarni vygenerovanych DI
• ➕ prezenter neriesi, odkial zavislosti tecu, ale _deklaruje_, ake sluzby sa maju pouzit
• ➕ lazy loading
• ➖ ziaden autowiring
• ➖ „maskovany“ service lokator / lazy manazer (❔)
• ➖ kontajner pri kompilacii nezisti problemy s chybajucimi alebo konfliktnymi sluzbami

Nechcem to propagovat ako univerzalne riesenie, ponukam to ako jednu z moznosti, kompromis, so svojimi vyhodami a nevyhodami. A som zvedavy na nazory a diskusiu, tak sa mozno dopracujeme k niecomu lepsiemu.

Editoval xr (10. 5. 2020 12:38)