Avatar
Michael Kufner:

Zdravím,
potrebuji vysvetlit, kdy je nejvyhodnejai pouzit jaky zpusob DI.
Mám HomepagePresenter a SettingsPresenter (pouze priklad) a oba dedi z BasePresenteru.
Budu chtit pouzivat service Databaze, bude potreba v kazdem presenteru (i v pripadnych budoucich), takze je lepsi to injectnout v BasePresenteru.
Jakym zpusobem? BasePresenter je abstraktni, takze konstruktor nepripada v uvahu. Metoda injectDatabase nebo pres anotaci a proc? Cetl jsem ze anotace rusi zapouzdreni, takze idealni je udelat v BasePresenteru metodu inject a o vic se nestarat?

Druha moznost, kdyz chci aby mel jenom Homepage presenter nejaky model (napr. ArticleManager). To muzu udelat konstruktorem, anotaci, inject metodou a nebo setterem. Me se zda nejlepsi v tomhle pripade pouzit konstruktor, aby nemel presenter zbytecne metod navic (inject), zaroven abych se o nic nemusel starat (setter) a zaroven neporusil zapouzdreni (anotace).

Shrnuto:
Chci pouzivat zavislost ve vice presenterech -> v abstraktnim BaseManageru udelat metody inject.

Chci pouzivat zavislost pouze v konkretnim Presenteru, jehoz zavislost neni dobrovolna, pouziju konstruktor ve final Presenteru. Je to ok?

 
Odpovědět 22. června 1:08
Avatar
Odpovídá na Michael Kufner
Martin Konečný (pavelco1998):

Předávat závislost konstruktorem je sice fajn, ale má to dvě nevýhody

  1. při větším počtu závislostí ti vznikne constructor hell (a to hned, když budeš mít třeba továrny na formuláře). A to nemluvim o tom, že bys ve všech presenterech musel volat rodičovský konstruktor - takže sehnat závislosti pro něj a ještě pro sebe.
  2. dané závislosti již musí mít instanci (tzn. musí se z nich udělat objekt, který se třeba vůbec nepoužije).

Běžně používám anotace a nikdy jsem s tím problém neměl. Často pak mám třeba

class Presenter
{

        /**
         * @var Model\User
         * @inject
         */
        public $userModel;

        /**
         * @var Model\Article
         * @inject
         */
        public $articleModel;

        /**
         * @var Model\Message
         * @inject
         */
        public $messageModel;

        /**
         * @var Forms\SendMessageFormFactory
         * @inject
         */
        public $sendMessageFormFactory;

        // atd.

}
Editováno 22. června 1:20
 
Nahoru Odpovědět 22. června 1:19
Avatar
Odpovídá na Michael Kufner
Dominik Gavrecký:

Ja ti naopak DI cez inject neodporúčam ... Jediná jeho výhoda oproti konštruktoru je to že menej píšeš ... Osobne som sa o túto problematiku zaujímal pár dni do zadu a zistil som že je to čisto na programátorovi David Grundl na jeho prednáškach odporúča Inject ale tiež uviedol ako jediný dôvod menej písania ale zas na druhú stranu písal som si s mnohými programátormi ktorý mi povedali že je lepšie používať konštruktor prečo ?

Budem citovať jedného z nich teda člena IT Tuníka

Typová kontrola a jasná specifikace existenčních závislostí.

Nahoru Odpovědět  +1 22. června 7:17
Hlupák nie je ten kto niečo nevie, hlupákom sa stávaš v momente keď sa na to bojíš opýtať.
Avatar
Odpovídá na Michael Kufner
Dominik Gavrecký:

Předávání závislostí pomocí konstruktoru je dostupné u všech vytvářených tříd, podobně pak použití setteru u nepovinných závislostí. Další techniky, tedy metody inject* a členské proměnné označené anotací @inject, jsou pak méně čisté techniky a jsou dostupné jen v presenterech, případně je možné je vynutit konfigurací u služeb vytvářených DI Containerem. Používáme je tedy pouze ve specifických případech, například u již zmíněných presenterů.

https://doc.nette.org/cs/2.4/di-usage

Nahoru Odpovědět  +1 22. června 7:30
Hlupák nie je ten kto niečo nevie, hlupákom sa stávaš v momente keď sa na to bojíš opýtať.
Avatar
Odpovídá na Dominik Gavrecký
Martin Konečný (pavelco1998):

Jak budeš řešit případ, kdy:

  1. BasePresenter má třeba 6 závislostí (nějaké modelové třídy, form factories, ...)
  2. bude od něj dědit nějaký presenter, který má další 4 závislosti
  3. takových presenterů budeš mít třeba 10 a pak se ti do BasePresenter přidá další závislost

ta čísla jsou tam náhodně, ale proto, aby vyjádřila větší počet těch závislostí. Jak to budeš řešit konstruktorem? Zvlášť u bodu c), kdy kvůli přidání jedné nové závislosti do BasePresenteru budeš muset upravovat všech zbylých deset presenterů, aby tu závislost jejich předkovi předaly.

Schválně jsem si propočítal, kolik takových závislostí mám v jedné aplikaci. BasePresenter jich má 13 a jeden větší presenter pod ním dalších 7. Tohle řešit konstruktorem, tak umřu :D

 
Nahoru Odpovědět  +1 22. června 13:43
Děláme co je v našich silách, aby byly zdejší diskuze co nejkvalitnější. Proto do nich také mohou přispívat pouze registrovaní členové. Pro zapojení do diskuze se přihlas. Pokud ještě nemáš účet, zaregistruj se, je to zdarma.

Zobrazeno 5 zpráv z 5.