přístup v modelu k ostatním modelům

Hutný dotaz :-)

Osobně bych asi nakonec skončil u toho, že PointGeneratoru bych předával přímo ty body. Nicméně by se hodila další třída, která tohle všechno zastřešuje, dostává svoje závislosti (EventModel, ScoreModel) a zajišťuje logiku celé té operace.

Snažil jsem se být stručný, je tomu alespoň trochu rozumnět?

Editoval arron (24. 4. 2012 22:48)

HosipLan wrote:

konstruktoru PointGeneratoru vyjmenuji všechny modely, které může kdy potřebovat

Tohle je z tvých vyjmenovaných ta nejlepší…

Ono totiž záleží na tom, co přesně ta třída PointGenerator dělá. Protože možná je to přesně ta, o které já mluvím jako o té „zastřešující“ :-) V tom případě jsme se s @HospiLanem shodli :-)

Editoval arron (24. 4. 2012 22:50)

Musím přiznat pánové, že z těch odpovědí nejsem tak úplně moudrý. Zareaguji na vaše připomínky odděleně.

arron napsal(a):
… PointGeneratoru bych předával přímo ty body. … další třída, která tohle všechno zastřešuje, dostává svoje závislosti (EventModel, ScoreModel)…

Jenom se ujistím: myslel's, „předával hodnoty“, ne „body“, že jo? Body tenhle objekt vytváří z hodnot jako skóre, vítěz, pořadí odpalování atd.

Rozdělení PointGeneratoru na zastřešující a jádro:
Tím ale jen odsunu problém jinam a řeším, jak předat modely tomu zastřešujícímu objektu. Nebo jsem tě nepochopil.

Editoval petr.pavel (25. 4. 2012 9:41)

HosipLan napsal(a):

…umožnit modelu přistupovat k jiným modelům

To nepotřebuješ. Máš sestavit graf tříd v DI Containeru – propojit je tím, že je navzájem předáš.

Promiň, ale tomuhle nerozumím. Co to je „graf tříd“? (Google jsem zkoušel.)
DI Container používám, parametry předáváné PointGeneratoru definuji v config.neon (což je zmíněná varianta 2) a samotný PG získávám přes $this->context->createPointGenerator(...). Jestli to není poznat z mého původního postu, řekni prosím, co tam chybí, doplním.

A nerozumím, proč konstatuješ, že nepotřebuji umožnit modelu přistupovat k jiným modelům, a přitom dál vysvětluješ, jak to udělat. Jestli to fakt nepotřebuju, tak jak má PG získávat vstupní hodnoty pro generování bodů?

…je hloupé předávat „všechny modely, které může kdy potřebovat“. Daleko jednodušší je předat ty, které zrovna teď potřebuješ.

To je nedorozumění: Nemyslel jsem klavír, myslel jsem opravdu jen ty, které potřebuje. Ono to není tak, že by konkrétně PG potřeboval hodně modelů. Potřebuje aktuálně myslím tři. Ale stejná situace je i u některých jiných modelů a jak refaktoruju, tak do toho seznamu použitých modelů musím furt hrabat. To je ta ruční práce, které se chci vyhnout.

Pokud jich potřebuješ moc, tak musíš třídu rozdělit na víc menších a ty složit do sebe.

Tohle už je relativní. Nemyslím, že by a priori bylo lepší nahradit dlouhou metodou složitou hierarchií objektů. V mém případě si myslím, že už to dál drobit není dobré a že PG dělá opravdu jen jednu práci a dělá ji dobře :-) Ze stejného důvodu nevidím, jak bych ho mohl ještě dál rozdělit na zastřešující a jádro (@arron).

Další věc je, že žádnou ruční práci dělat nemusíš. Když budeš důsledně psát typehinty, tak za tebe všechno udělá autowiring.

Tohle je moje definice PG v Neonu:

factories:
		pointGenerator:
			class: PointGenerator(..., %constants%, %customization%)
			parameters: [event, eventModel, scoreModel]
			setup:
				- $event(%event%)
				- $eventModel(%eventModel%)
				- $scoreModel(%scoreModel%)

class PointGenerator extends BaseModel {
  // nemá konstruktor
}

abstract class BaseModel extends NObject {
public function __construct(NotORM $database, $constants, $customization) {
	// $constants a $customization jsou parameters/constants a parameters/customization z Neonu
}
}

Nevím, jak tohle vylepšit typehintováním a kam ho narvat. Nakonec možná ani nebude dědit BaseModel, nechci z PG přistupovat do db přímo, ale jen prostřednictvím modelů.

Typehintování přece taky bude v nějakém seznamu (nejspíš v seznamu parametrů konstruktoru PG), takže si nepomůžu. Zase je to seznam, který musím ručně upravovat.

EDIT: Oprava definice PG v Neonu.

Editoval petr.pavel (25. 4. 2012 10:22)

vojtech.dobes napsal(a):
Proč ten PointGenerator nefunguje jako služba?

Já myslel, že služba se od továrny liší jen tím, že služba si hlídá, aby měla jen jednu instanci, a tím, že továrně lze předávat při volání parametry. Jedinou instanci nepotřebuji, zatímco parametr předat potřebuju – id turnaje, pro který body počítám.

No, a PointGenerator má asi nějakou public metodu (jak se jmenuje?). Té bych předával pak konkrétní turnaje atd. (myslím entity).

Má veřejné metody getEvent(), generate() a save(). V podstatě rozdělení procesu přiřazení bodů na fáze, které volám z presenteru a po kterých případně přesměruji uživatele s chybovou hláškou. Souhlasím, že pokud nějaký model/službu potřebuju volat jen v jedné metodě, měl bych ho předávat rovnou té metodě. Jenže ty modely, které předávám PG přes továrnu, potřebuje víc metod (i některé private). Takže bych řekl, že to předávání továrně je v tomhle případě košer.

Se zbytkem souhlasím, pěkně napsáno. Předávám data jen za účelem výpočtu. Resp. předávám modely proto, aby mohly být zavolány pro získání dat potřebných pro výpočet :-)

Původně jsem chtěl debatovat o problému obecně, ale vidím, že to asi nejde a že vždycky záleží na konkrétní situaci.

petr.pavel napsal(a):

Promiň, ale tomuhle nerozumím. Co to je „graf tříd“? (Google jsem zkoušel.)

Graf tříd je, že je skládáš do sebe.

$a = new A(new B(new C), new D(new E, new F(...)));

Připomíná to totiž graf ;)

A nerozumím, proč konstatuješ, že nepotřebuji umožnit modelu přistupovat k jiným modelům, a přitom dál vysvětluješ, jak to udělat.

Nepotřebuješ modelu umožnit kamkoliv přistupovat, když mu to, kam potřebuje přistupovat, předáš. Hollywood: „Nevolejte nám, my zavoláme vám.“

Nemyslím, že by a priori bylo lepší nahradit dlouhou metodou složitou hierarchií objektů.

No, a já si to myslím :)

Tohle je moje definice PG v Neonu:

Samozřejmě, parametry si musíš předat ručně. To je přeci jasné, jak bys to chtěl napsat jednoduššeji? To prostě nejde. Někde to napsat musíš, ať v configu, nebo třeba někde v kódu. Tomu se nevyhneš. A v configu je tomu lépe.

Proč je to factory? Udělal bych raději třídu, která by přijímala parametry metodou, které jí teď předáváš konstruktorem, a vracela ti nějaký jiný objekt, nakonfigurovaný :)

class PointGenerator extends Nette\Object
{
	// ...
	public function generate($event) // eventModel, scoreModel ??? předat konstruktorem!
	{
		return new MatchPoints($this->eventModel, $this->scoreModel, $event);
	}
	// ...
}

$matchPoints = $generator->generate(10);
$matchPoints->add(10);
$matchPoints->save();

Třeba, nebo tak něco. Z tvého kódu mám pocit, že máš dopletené co je to entita.

Prostě to máš špatně navržené, kdyby ne, tak tyhle problémy neřešíš :)

@HosipLan: Díky za vysvětlení a ukázkový kód. Myslím, že chápu, jak's to myslel. Vypadá to jako akademicky čisté řešení, na pohled se mi líbí :-)

Nechce se mi ale štěpit jeden 300 řádkový soubor na 10 tříd celkem o 400 řádcích. Takhle mám veškerou logiku generování/počítání bodů na jednom místě, nemusím lítat od čerta k ďáblu, když hledám, jak se vlastně body počítají.

Z tvého kódu mám pocit, že máš dopletené co je to entita.

To je možné, těžko říct. Entity jako takové nepoužívám vůbec (resp. ne v této části) a nechybí mi.

Prostě to máš špatně navržené, kdyby ne, tak tyhle problémy neřešíš :)

Určitě to mám špatně navržené. Teď už jen přijít na to, jak je to správně ;-)

Pravdu máš v případě, že veškeré modelové služby bez výjimek mají přesně ty samé parametry konstruktoru. To mi přijde ale dost zvláštní, u mě se tohle nestává. Pokud bude jedna modelová service chtít využít jiné service, jak to uděláš?

Nelíbí se mi taky to, že presentery a další třídy přistupují k „modelům“ přes nějakého prostředníka, jehož úkolem je řešit jen ty stejné parametry konstruktorů modelových tříd. Ale co je presenteru po tom, jak se která služba vyrábí? On je chce dostat všechny stejně.

@Honza Marek: Nad zápachem stejných parametrů předávaných konstruktoru modelu se zamyslím, díky.
Když potřebuji předat jiné služby (jako např. v případě PointGeneratoru), tak nepoužívám model loader ale žádám rovnou context.

Ale co je presenteru po tom, jak se která služba vyrábí? On je chce dostat všechny stejně.

Tohle jsem asi nepochopil. Když nebudu používat model loader a vždy budu žádat context, tak sice budu v presenteru všechny modely získávat stejně, ale moc nevím, v čem/proč je to lepší. Teď „běžné“ modely získávám přes model loader a „speciální“ přes context.

Možná by pomohlo z úvah úplně vypustit slovo model a dívat se na to jako na obyčejné třídy. Neexistuje nic jako „modely“.

@David Grudl: Obecně máš pravdu a pak by vlastně tvůj seriál o DI řešil stejnou otázku (což je do jisté míry pravda).

Moje otázka je víc v kontextu Nette, kde mám:

• model loader, který mi inicializuje objekty a předává jim výchozí parametry (všem modelům stejné)
• config.neon, jeho definice továren s možnosti nastavit hodnoty objektu předanými hodnotami (i jinými z configu)
• a DI kontejner, který mi zprostředkovává přístup k továrnám z config.neon

Dosavadní odpovědi se hodně věnovaly obecné architektuře, což nebylo vyloženě na škodu, pořád ještě nad nimi přemýšlím.

Původně jsem ale čekal spíš odpověď typu:
Nejčistší je předávat všechno v parametrech konstruktoru nebo metodě, což lze za okolností xyz usnadnit přes config.neon, ale naopak za okolností abc si tím spíš přiděláš práci. Za okolností def je pak lepší situaci chápat jako ghf, při níž je zcela v pořádku předávat celý container a nechat model ať si z něj vytahuje, co potřebuje.

V souvislosti s unit testováním zjišťuji, že je nejlepší funkcionalitu modelu rozdrobit tak, jak moc podrobně ji chci testovat, a předávat všechny závislosti v parametrech. Přiznám se ale, že podvádím. Místo toho, abych údaje o turnaji zjišťoval přes TurnajModel, hrabu rovnou do databáze. Právě proto, abych si nemusel předávat tucet modelů, z nichž z každého si zavolám jednu metodu.