Inject repozitáře do vlastní služby

No to je preto, lebo @inject funguje len v presenteroch (dá sa síce zmeniť ale neodporúča sa to) v ostatných prípadoch je nutné použiť konštruktor. Ps. (nieje to __constructor ale __construct).

class ObjectService {

    /** @var \App\Model\StudentsRepository */
    public $StudentsRepository;

    public function __construct(\App\Model\StudentsRepository $studentsRepository){
        $this->StudentsRepository = $studentsRepository;

    }

}

Editoval Unlink (5. 8. 2015 21:58)

To by lepší nebylo. Věř mi, vím o čem mluvím :-)

Když už to děláš jako třídu, tak nikdy nevíš, kde ji budeš ještě potřebovat a pokud by jsi tam dal context, tak pak bude peklo to přenést do jiného projektu a zjišťovat kdeže ti to padá, jaká tabulka chybí atd. Ty závislosti prostě budou schovaný.

Nejlepší řešení IMHO je přes constructor dát věci bez kterých ta třída nemůže fungovat (ideálně jako interface). Protože když to přeneseš do jiného projektu, tak stejně tam ty třídy musí být. To co není bezpodmínečně nutný pro funkci třídy předávat setrem.

Edit: ještě si můžeš vypomoct nějakou třídou, která bude agregovat některé repositáře. Např. jeden agregátor může obsahovat articleRepo, commentRepo, userRepo, … Ale to se mě taky neosvědčilo.

Editoval Oli (5. 8. 2015 22:51)

Čistěji určitě ne. Konstruktor je pro povinné závislosti nejčistější možnost. Ta anotace u presenterů je naopak velmi špinavý způsob, ale presentery mají několik specifických vlastností kvůli kterým se to toleruje (např. konstruktor předka vs. konstruktor potomka). Pokud bys to ale chtěl čistě, tak bys u abstraktních presenterů použil anotaci (nebo metodu inject*) a u konkrétních presenterů taky konstruktor.

Jestli máš dvacet závislostí, tak to vypadá spíš na třídu, která dělá příliš mnoho věcí a tedy porušuje princip jediné odpovědnosti. Pokud ne a třída je nějaká velmi speciální, pak by bylo možné předat celý kontext, ale musíš vědět, že je to hack a proč to děláš. Rozhodně to není čisté řešení.

A constructor je lepší řešení, než toto? Osobně se mi tohle líbí víc. Můžu si to dělit do bloků po pěti a podobně:

//config
services:
    service2:
        class: App\Service2
        setup:
            - setAnotherService

//model
class Service2
{
    private $anotherService;

    public function setAnotherService(AnotherService $service)
    {
        $this->anotherService = $service;
    }
}

V tomhle případě je to asi nastejno. Nevýhodu vidím v tom, že ti tímhle strašně nabobtná kod. Přidáním další závislosti bys měl o 1 řádek víc v constructoru, ale o 4 řádky víc u tvého řešení. A to ještě nemluvím o tom, že budou mezi metodama prázdný rádky. Takže dejme tomu 5× víc kodu (místa) pro předání závislostí.

Settery vnímám zejména jako nepovinné závislosti. Nemusí to být pravidlem, ale snažím se dodržovat to, že na čem je třída existenčně závislá, tak je v konstruktoru. Pak to je hned zřejmé, když přijdu ke kodu po roce, tak vím, co je nutné a co je nepovinné

Editoval Oli (8. 8. 2015 15:04)

Principiálně to výjde na stejno. A v podstatě se snažím o to o čem mluví Oli. Nechci mít nabobtnalí kód. A osobně nevidím nic lepšího na tom že budu mít třeba 4 settery po pěti repozitářích nebo jeden konstruktor o dvaceti repozitářích. I tak děkuji za snahu :)

Nevyjde to nastejno. Je špatně že máš desítky závislostí v třídách a je špatně že je předáváš přes settery, když jsou povinné. https://filip-prochazka.com/…cky-posobota

Fajn přednáška. V podstatě co bylo řečeno jsem pochopil, pročítáním dokumentace a tady fóra.
O co šlo zde jsem vyřešil. Pak už jsem jen řešil to co je nejlepší kombinace čístěho a elegantního/pěkného řešení. Když to vyreším čistě, bude to otřesně výpadat a přehlednost strašná.

Děkuji moc za odpověď a přednášku :)

Pravděpodobně pak ale nemáš úplně dobře návrh logiky :-) Nikdy jsem to nezkoumal, ale řekl bych, že mám průměr tak 5 závislostí na třídu.

A proč nemůžeš tu třídu rozdělit na více tříd? Každá pak bude mít méně závislostí.