Vytvoření \Nette\Database\Context v předkovi

No musel bych tady do konstruktoru dávat Context že jo? bez toho to nejde? to mi přijde dost svazující, když mám vždycky předepsáno jak bude konstruktor vypadat. a pak i ta třída Base ztrácí skoro smysl. můžu si proměnnou database přenést sem…

No parent::__construct() je jasné že tam napíšu. ale on chce Context. takže stejně budu muset v každém potomkovi vytvořit Context. Já bych byl rád, abych ho měl v potomcích vždy už připraven a nemusel jsem ho tam vytvářet..

No jo, ale to potom toho potomka musím uvést v config.neon že jo? a tím pádem už nemůže mít jiné parametry…

No tuhle třídu budu vytvářet pomocí faktory v jiné třídě. ale to první řešení v presenteru je rozumné, už tomu pomalu začínám rozumět. Ale moc nerozumím tomu s DI kontejnerem, jak to bude fungovat? můžeš mi to prosím trochu rozepsat? v potomcích nechci předávat jiné služby, ale i nějaké proměnné.
Já se omlouvám, možná jsem trochu natvrdlý ale je to pro mě nové a přijde mi že je to dost komplikovaný. Navíc to člověku dost svazuje ruce s nějakým objektovým návrhem, s návrhovými vzory, když musím předávat třídy frameworku…
Nevidím v tom žádnou výhodu.

bluray: On ten OOP přístup má tu výhodu, že by to mělo „přiblížit“ programování reálný situaci. Je to jinej pohled na problém. Ty návrhový vzory nemusíš znát. Pravdou ale je, že návrhový vzor je best practice, neco co se pro daný problém ustálilo jako optimální řešení, proto, pokud to myslíš vážně se jim asi stejně nevyhneš. Alespoň nějakých 5 vzorů budeš postupně využívat ;-)

Jednu z největších praktických výhod vidím v oddělení zodpovědností a závislostí. Například, když máš vypsat data uživatele, tak víš, že se o to stará třída UserManager. Ta třída má závislost (kterou zpravidla najdeš v konstruktoru) např na UserRepository, která tahá ty data z databáze. Jsou to oddělené zodpovědnosti a pokud máš takových objektů (jako je User) třeba 50, tak to potom hodně zpřehlední.

Chci pracovat s komentářema pod článkem, otevřu si třídu CommentsManager, která se o to stará. Potřebuju dostat komentáře z databáze: vlezu do CommentsRepository, protože vím, že to je můj „přístupový bod“ do databáze…

Doufám, že nepopisuju kolo, ale podle tvého příspěvku mě přišlo, že právě tohle ti není uplně jasné. Jestli jsem to blbě pochopil, tak se omlouvám za OT :-)

Uf, no že to dalo práce, najít téma, ve kterém se řeší můj problém (místo zakládání nového). :) Tušil jsem, že tohle už někdo prostě řešit musel. Takže, jen abych se ujistil, vážně není jiná možnost, než předávat Context i v konstruktorech potomků? Můj problém ve zkratce:

Mám v modelu abstraktní třídu Base, která obsahuje klasické získání závislosti přes konstruktor (DB):

namespace App\Model;

use Nette;

abstract class Base extends Nette\Object
{
    /** @var Nette\Database\Context */
    public $database;

    public function __construct(Nette\Database\Context $database)
    {
		$this->database = $database;
    }
	…

A nějaké obecné metody (selectById(), selectAll(), update(), delete() a tak dále). Od této třídy odvozuji další součásti (třídy) patřící do modelu. Co když chci v potomkovi další závislosti? Musím to řešit nějak takhle:

public function __construct(Nette\Database\Context $database, Cities $cities, Nette\Http\Request $httpRequest)
{
		parent::__construct($database);
		$this->cities = $cities;
		$this->httpRequest = $httpRequest;
}

Zkrátka, musím znovu předávat Context. Připadá mi to takové hloupé. Jak už psal někdo nahoře: jedním z důvodů proč nějakou třídu Base mám, bylo právě to, abych nemusel v každé nové třídě modelu znovu do konstruktoru vypisovat Context. Ale co já vím, jak by řekl Homer: Jsem tady první den. :)

A na závěr otázka, proč mi v modelu nefunguje

@inject

? Co jsem kde přehlídnul?

Díky všem za odpovědi a čas.

Edit: A teď mi ještě došlo, že i tak mám smůlu, pokud nechám Base jako abstraktní, protože bez instance se konstruktor volá těžko, žejo. :D

Editoval Džůny (10. 5. 2015 14:52)

Jak pise @dyamon, jen doplnim, ze to inject muzes zapnout i jinde prepsanim:

services:
	- MyModel

na

services:
	-
		class: MyModel
		inject true
#respektive zkracene na
	- {class: MyModel, inject: true}

Od 2.3 pak toto muzes zapnout treba pro vsechny potomky Base modelu:

decorator:
	App\Model\Base:
		inject: true

Ale pouzivani inject properties neni mimo presentery doporucovano

Mohl bych se zeptat, jak moc je používání takovéhle abstraktní base třídy pro model používané? Přijde mi to jako docela antipattern. Jsem v tom sám nebo to tak připadá více lidem?

sice je pravda, že insert a findById mám v každé repository třídě…ale proboha, když mám objekty, tak tohle neřéká, jaký objekt mi to z té databáze vrací…

@dyamon To je mi jasné. Chtěl jsem se dozvědět, jestli není možnost hodit tuhle práci na Nette (DI Container) a nějak to zautomatizovat (jinak než pomocí @inject, když to není doporučováno a defaultně povoleno).

@DavidMatějka, @Šaman díky za informace a nabídnutí možností.

Ještě se teda zeptám, proč @inject není dobré používat mimo presentery? Proč je to u BasePresenter(u) OK a v modelu ne?

@Azathoth Nejsi sám, ono se to tady dost řeší, co jsem tak zběžně koukal. Ale viděl jsem to v několika projektech takhle, hádám, že je to zkrátka nejsnazší a nejjednodušší. Když se nad tím člověk zamyslí (a nad alternativama), tak mi to připadá prašť jak uhoď…

a co takhle používat setterovou inkjekci? To by problém nevyřešilo?

Aha, pardon, už to vidím, jsem slepý.