Závislost jednoho modelu na jiných

Krok 4

No a teď k tomu posílání zpráv a Kdyby\Events, na které ses ptal. :) Teď už je úplná brnkačka obohatit hráče o události, které se vyvolají při vydání či přijetí předmětu:

Šlo by přepsat do verze bez transaction hell

<?php
/**
 * @method onItemGiven(Player $player, Item $item)
 * @method onItemReceived(Player $player, Item $item)
 */
class Player extends Object
{

	/**
	 * @var Closure[]
	 */
	public $onItemGiven = [];

	/**
	 * @var Closure[]
	 */
	public $onItemReceived = [];

	/**
	 * @var string
	 */
	private $id;

	/**
	 * @var Item[]
	 */
	private $items = [];



	/**
	 * @param string $id
	 */
	public function __construct($id)
	{
		$this->id = $id;
	}



	/**
	 * @param Item $item
	 * @throws InvalidArgumentException
	 */
	public function giveItem(Item $item)
	{
		if (!$item->isInTransaction()) {
			throw new InvalidArgumentException("Cannot give item that isn't in transaction.");
		}
		$index = array_search($item, $this->items, TRUE);

		if ($index === FALSE) {
			throw new InvalidArgumentException("Player doesn't own requested item.");
		}

		unset($this->items[$index]);
		$this->onItemGiven($this, $item);
	}



	/**
	 * @param Item $item
	 * @throws InvalidArgumentException
	 */
	public function receiveItem(Item $item)
	{
		if (!$item->isInTransaction()) {
			throw new InvalidArgumentException("Cannot receive item that isn't in transaction.");
		}
		$index = array_search($item, $this->items, TRUE);

		if ($index === FALSE) {
			$this->items[] = $item;
			$this->onItemReceived($this, $item);
		}
	}

}



class Item
{

	/**
	 * @var int
	 */
	private $id;

	/**
	 * @var Player
	 */
	private $owner;

	/**
	 * @var bool
	 */
	private $isInTransaction = FALSE;



	/**
	 * @param int $id
	 * @param Player $owner
	 */
	public function __construct($id, Player $owner)
	{
		$this->id = $id;
		$this->owner = $owner;

		$this->doInTransaction(function () use ($owner) {
			$owner->receiveItem($this);
		});
	}



	/**
	 * @param Player $newOwner
	 */
	public function changeOwner(Player $newOwner)
	{
		if ($this->owner !== $newOwner) {
			$this->doInTransaction(function () use ($newOwner) {
				$this->owner->giveItem($this);
				$this->owner = $newOwner;
				$this->owner->receiveItem($this);
			});
		}
	}



	/**
	 * @return bool
	 */
	public function isInTransaction()
	{
		return $this->isInTransaction;
	}



	/**
	 * @param Closure $callback
	 */
	private function doInTransaction(Closure $callback)
	{
		$this->isInTransaction = TRUE;
		$callback();
		$this->isInTransaction = FALSE;
	}

}
?>

Je vhodné, aby hráč vůbec nevěděl o nějaké messages vrstvě aplikace, a proto jsou eventy velmi dobrým způsobem, jak ty notifikace naimplementovat.

No a proč jsem se o tom takhle rozepsal? Protože tohle je tak nějak objektový přístup a přístup, ve kterém Ti pak jdou úplně na ruku nástroje jako Doctrine 2 nebo právě Kdyby\Events.

Kdyby ses totiž ve výše uvedené ukázce rozhodl mít hráče, předměty a vztahy mezi nimi persistované v relační databázi, jediné, co bys při použití Doctrine 2 musel udělat navíc, by bylo napsat nad properties těch tříd pár anotací. :)

Editoval Tharos (27. 2. 2015 1:53)

Děkuji za obsáhlou odpověď! Snad tvé první dvě věty nebyly myšleny ironicky, opravdu jsem to tu měl dlouho otevřené a snažil se najít správné věty :D

V MVC/MVP se mi zatím nepodařilo psát objektově tak hezky, protože vždy byly určité problémy, mezi které hlavně patří, jak objektům předat spojení s databází (bez toho bohužel nejde obyčejné new Obj($id).
Doctrine bohužel neovládám a v nejbližší době určitě nebudu. Nejsem si jistý, zda jsem tvé příklady pochopil správně.

Nejdříve bych si rád ujasnil jinou věc. Budu chtít:

1. Získat seznam všech předmětů ve hře. To bude nejspíš řešit nějaká služba s názvem třeba ItemService.
2. Manipulovat s určitým předmětem (změnit vlastníka atp.). To by měla řešit jiná třída, např. Item.

Pokud chápu správně, pak by jedna třída neměla reprezentovat určitý předmět a zároveň umět vrátit seznam všech předmětů v nějakém poli. Jednalo by se o porušení single responsibility. Je to tak?

Co se týká samotného tématu. Pokusím se vytvořit praktický příklad. Dokázal bys mi, prosím, upřesnit pár nejasností?

Použijeme databázi MySQL, ve které budou tabulky player (id, name), item (id, ownerId, place (kde předmět je – inventář, tržiště, …)) a message (id, recipientId, content).
Cílem je, že:

1. Hráč na stránce klikne na odkaz „koupit předmět“
2. Zpracuje se signál pomocí metody handleBuyItem()
3. Upraví se řádek v tabulce item (změní se ownerId a place (z tržiště na inventář), nebudeme teď řešit, zda má hráč dostatek peněz apod.)
4. Oběma hráčům se odešle zpráva (2× insert do tabulky message)

Dle zažitého postupu bych to řešil nějak takto:

<?php

class BasePresenter extends Nette\Application\UI\Presenter
{

	/** @var Player */
	protected $player;

	// jak injectovat objekt třídy Player, aby mohl i komunikovat s databází?
	// možná by se to řešilo pomocí továrničky

	/** @var PlayerFactory @inject */
	protected $playerFactory;

	public function startup()
	{
		parent::startup();
		$this->player = $this->playerFactory->create($this->user->id);
	}

}

class MarketPresenter extends BasePresenter
{

	/**
	 * @param int $id
	 */
	public function handleBuyItem($id)
	{
		try {
			$this->player->buyItem($id);
		} catch (Nette\InvalidArgumentException $e) {
			$this->flashMessage($e->getMessage());
			$this->redirect("default");
		}
	}

}

class Model
{

	/** @var Nette\Database\Context */
	protected $db;


	/**
	 * @param Nette\Database\Context
	 */
	public function __construct(Nette\Database\Context $db)
	{
		$this->db = $db;
	}

}

class Player extends Model
{

	/** @var int */
	private $playerId;

	/**
	 * @param int $id
	 * @param Nette\Database\Context $db
	 */
	public function __construct($id, Nette\Database\Context $db)
	{
		parent::__construct($db);
		$this->playerId = $id;
	}

	/**
	 * @param int $id
	 */
	public function buyItem($id)
	{
		// jak vyřešit modifikaci záznamu v tabulce `item`?
		// o to by se měla postarat spíš metoda ve třídě Item
		// zároveň je potřeba zjistit ID vlastníka daného předmětu, proto by zde objekt třídy Item měl být

		// jak zde vyřešit odeslání zprávy oběma hráčům?
		// je potřeba vytvořit instance třídy Message až zde, protože teprve uvnitř metody zjistíme ID vlastníka předmětu
	}

}

?>

Nějak takto je (nebo alespoň byl, když jsem začínal) popsán postup v Nette. Místo Player tam ještě byla nějaká service třída, která přijímala i ID hráče v metodě buyItem a vůbec ho nepoužívala jako atribut.
Je proto dost možné, že na to jdu špatně.

Pokud nebudu používat vychytávky jako je Doctrine, ale s databází pracovat jednoduše pomocí SQL příkazů uvnitř metod modelů, pak mi přijde, že se objevuje několik problémů, kvůli kterým by mi tvůj příklad úplně správně nefungoval.

@Magnus

Poměrně důležitá věc je si uvědomit jednu řekněme základní věc. Nesnaž se chápat modelovou vrstvu jako něco co má přesně opisovat strukturu databáze. Není úplně běžné, že by se modelová vrstva skládala pouze z repository a entitních tříd, které by odpovídaly tabulkám v DB. Velmi často se repository nepoužívají „na přímo“, ale obalují se do Fasádních tříd, které sdružují a obstarávají zpracování složitějších operací. Fasády se pak většinou i „jednodušeji“ používají lidem, kteří neznají dobře implementaci entit a repositářů, protože mají zpravidla přívětivější interface.

Fasáda je pak v podstatě třída „SalesManager“, na kterou naráží @duke.

Tharos napsal:

@duke: Moc díky za Tvou ukázku, protože úplně krásně demonstruje jednu věc. :)

Také děkuji za reakci.

Ty jsi tu transakční logiku přesunul z entit do servisní vrstvy, která nad těmi entitami operuje. Z mého pohledu jde o přechod od „spíše objektového“ řešení ke „spíše procedurálnímu“…

Pravdou je, že věc lze řešit:

1. v entitách
2. v servisní vrstvě nad nimi

Asi jsem se nevyjádřil úplně přesně, ale šlo mi o to, že ať tak či onak, měly by entity/služby samy řešit jen to, co jim náleží (vše, co se týká jich samotných) a nic nad to. V tomto ohledu byl můj argument neutrální vůči tomu, zda pro logiku použít entitu, či servisní vrstvu.

Poté jsem doporučil zapouzdřit prodej do třídy Sale (kterou bych s dovolením chápal spíš jako entitu než službu). Smyslem nebylo přenést kód z entit do servisní vrstvy, ale přenést ho z místa, kam IMHO nepatří (z logiky hráčů a věcí), na místo, kam patří (do logiky prodejů, ať už je prodej realizován jako entita či jinak).

Z mého pohledu jde o přechod od „spíše objektového“ řešení ke „spíše procedurálnímu“

Spíše procedurální by to asi bylo, kdyby neexistovala ta třída Sale a celý prodej byl realizován jen nějakou metodou ve službě, např. SalesManager::sell($seller, $buyer, $item). Pokud je ale prodej vyjádřen instancí třidy Sale, nedokážu si představit více objektové řešení.

…a vidím v něm hned několik z toho vyplývajících nevýhod:

• Tvůj model už není nerozbitný, snadno jej přivedu do nekonzistentního stavu (v praxi samozřejmě nechtěně). Stačí, když někde zavolám releaseItem, čímž odeberu hráči předmět, ale zapomenu pak upravit informaci v předmětu, komu že patří.

Nesnažil jsem se o nerozbitný model, ale o přehledný model. Když se chce, rozbít jde cokoli.
Mimochodem různé pojistky podobné tvému doInTransaction by v řešení s třídou Sale jistě mohly být také.
Nevím ale, zda něco jako isInTransaction do entitní třídy Item z hlediska SRP patří, neboť zodpovědností entity Item jistě nejsou nějaké transakce, o kterých Item vůbec nic neví (transakce probíhají nad ní). Spíše mi to připadá jako takový hack (to, co má být nad, je přesunuto dovnitř), který sice někdy může být užitečný, ale bál bych se ho využívat ve velkém. Protože, když takovou metodu může mít Item, proč ne i Player a všechny ostatní entity, a kdo si pak má pamatovat, kdo musí být při jaké operaci v transakci, a kdo naopak ne. Půlka kódu v entitách by pak také mohla být o tom, zda to či ono je v transakci. Pak bychom pro to mohli ještě vynalézt nový pojem, např. transaction hell.

• Přibyl setter setOwner, který mohu zavolat s jakýmkoliv parametrem a zase tím narušit konzistenci (třeba nastavím jako vlastníka jiného hráče, než který má aktuálně předmět mezi svými předměty).

IMHO je lepší takovéto chyby řešit testováním. Mám za to, že mít o něco více nerozbitný model za cenu znepřehlednění kódu oním transaction hell nestojí. Ale třeba se pletu…

• Musím vědět, že změna vlastníka se má dělat přes třídu Sale. Když to nebudu vědět, model mi nezabrání udělat to jinak, nesprávně.

Ale změna vlastníka se nemusí dělat přes třídu Sale, nýbrž se má dělat metodou Item::setOwner. Ano, není to zabezpečené z hlediska konzistence. Pokud bych potřeboval zajištění konzistence, asi bych si to zapouzdřil do třídy ItemTransfer (Sale by ji mohla rozšiřovat). A ano, pak bych si musel pamatovat, že pokud chci praktikovat bezpečnou změnu vlastníka, je třeba ji dělat přes třídu ItemTransfer. :-)

• Co se stane, když zavolám (nechtěně) dvakrát Sale::execute po sobě?

Vyhodí to výjimku ItemNotOwnedException (při volání $this->seller->releaseItem($this->item)).

No a teď by mě zajímalo, jestli to řešení má i nějaké výhody?

Doporučuji zagooglit na téma výhody respektování single reponsibility principu.
Ale mohu něco ocitovat:

• Code complexity is reduced by being more explicit and straightforward
• Readability is greatly improved
• Coupling is generally reduced
• Your code has a better chance of cleanly evolving

Editoval duke (27. 2. 2015 0:54)

duke napsal(a):

Asi bys to mohl ještě více zpřehlednit, kdybys povolil NULL u ownera itemu a místo $this->isReleased prostě pracoval s $this->owner === NULL…

To vím, ale tím bych výrazně změnil zadání. :) A celou věc zjednodušil, což jsem záměrně nechtěl.

Vedlo by to pak třeba i k nullable FK v databázi a pokud by například předmět bez vlastníka byl z doménového pohledu nesmysl, zbytečně by sis vytvořil prostor, kde by Ti mohl vznikat nepořádek v datech.

Nicméně jádro problému je o tom, zda logika změny vlastnictví věci je něco, co se týká jen věci samotné a měla by to tudíž řešit věc sama, či zda je to něco, co se týká také jejího okolí (v tomto případě vlastníka), a mělo by to být tudíž řešeno někde vně. V mém příkladě je tím vnějším místem třída (entita) Sale či ItemTransfer. Dle mého názoru prostě není zodpovědností entity Item řešit konzistenci svého vlastníka, nýbrž jen svou vlastní. O konzistenci transferu věci (tj. všeho, co mu podléhá, tj. věci a vlastníka) ať se postará ItemTransfer.

To už je na uvážení každého. Nicméně pokud pracuješ například s Doktrínou, předpokládá se spíše to, že obousměrné asociace a jejich konzistenci (rozuměj konzistenci vlastnící a inverzní strany) si entity interně spravují samy (prostě viz zapouzdření). Můžeš se podívat třeba přímo do tutoriálu k Doctrine:

class Bug
{
    // ...

    public function setEngineer($engineer)
    {
        $engineer->assignedToBug($this);
        $this->engineer = $engineer;
    }

Tvé řešení jistě také bude fungovat, jen budeš mít vnější logiku nějak asymetricky rozdělenou uvnitř relevantních entit (v diskutovaném případě je asymetrie dána také vztahem 1:N, což tě patrně vedlo k Tvé volbě, nicméně představ si tentýž problém u vztahu 1:1 – která entita by pak volala isReleased? – tam bys musel volit naprosto libovolně). Budeš pak chtít opravit něco, co souvisí se změnou vlastníka, a budeš se muset ptát: dal jsem to do Itemu nebo do Playera? Já tuto otázku řešit nebudu, protože tu logiku nebudu mít na dvou místech a v entitách Item a Player budu mít jen logiku týkající se jich samotných.

Říká se tomu vlastnící a inverzní strana asociace. Existují pravidla a vodítka, podle čeho je u jednotlivých typů asociací určit.

Vlastně by se dalo říci, že Tvé řešení je tendenční, neboť nadřazuje Item Playerovi. Stejně tak ses mohl rozhodnout obráceně. Mé řešení je naproti tomu naprosto nestranné. :-)

V mém řešení je prostě jen vlastnící stranou té asociace předmět. To není nic tendenčního. :)

Tvé řešení je možná nestranné /ať to v praxi znamená cokoliv :)/, nicméně konzistenci stavu asociace mezi dvěma entitami řešíš mimo ty entity.

Editoval Tharos (27. 2. 2015 3:35)

Magnus napsal(a):

Použijeme databázi MySQL, ve které budou tabulky player (id, name), item (id, ownerId, place (kde předmět je – inventář, tržiště, …)) a message (id, recipientId, content).
Cílem je, že:

1. Hráč na stránce klikne na odkaz „koupit předmět“
2. Zpracuje se signál pomocí metody handleBuyItem()
3. Upraví se řádek v tabulce item (změní se ownerId a place (z tržiště na inventář), nebudeme teď řešit, zda má hráč dostatek peněz apod.)
4. Oběma hráčům se odešle zpráva (2× insert do tabulky message)

@Magnus: Až budu mít chvilku, rád Ti tohle celé pro inspiraci naimplementuji (s použitím Nette, Kdyby\Doctrine a Kdyby\Events). Jen prosím o chvilku strpení. Strávil jsem v tomhle vlákně nakonec o něco víc času, než jsem plánoval, a teď mi trochu chybí jinde. :)

Editoval Tharos (27. 2. 2015 14:40)

@Tharos Beru na vědomí, že v Doktríně je toto řešení běžné. Stále ale nejsem přesvědčen o tom, zda je to z hlediska SRP správně (Item prostě jednak řeší své vnitřní chování a nad to ještě zajišťuje synchronizaci s Playery, a to chápu jako 2 různé zodpovědnosti). Nicméně chápu, že toto řešení má i své výhody (zejména odolnost proti rozbití konzistence nevhodným použitím), takže jej zcela nezatracuji. :-)

Tou tendenčností jsem měl na mysli to, že když se řeší synchronizace obousměrné vazby, je třeba si vybrat jednu stranu, která tu synchronizaci řídí (vlastnící strana). Chápu, že Doctrine na to má své konvence, ale např. pro vazbu M:N uvádí: „You can pick the owning side of a many-to-many association yourself.“

Tvé řešení je možná nestranné /ať to v praxi znamená cokoliv :)/, nicméně konzistenci stavu asociace mezi dvěma entitami řešíš mimo ty entity.

Ano, protože i ten jejich vztah nechápu jako něco, co je vlastněno jednou či druhou stranou, nýbrž jako něco, co je mezi nimi a je jaksi sdíleno. Snažím se prostě řešit problém tam, kde se nachází a ne jinde. Tj. problém konzistence(synchronizace) stavu obousměrné asociace mezi dvěma entitami vnímám jako problém celého modelu (minimálně modelu těchto dvou entit) a ne jako vnitřní problém těchto entit. Možná si to tím na jedné straně komplikuju, ale zase nijak strukturu modelu nedeformuji.

Každopádně díky za zajímavou diskusi.

@FilipKlimeš Nesnažím se propagovat anemický model. Jsem pro, aby logika byla řešena v entitách, ale jen jim podřízená logika, nikoli logika, která se týká (také) jejich okolí. Cokoli vnějšího by mělo být řešeno spíše přes systém událostí.

Za sebe (z pohledu méně zkušeného programátora) dávám palec nahoru upravenému řešení od @Tharos a to ze dvou čistě praktických důvodů:

• Je to přehledné, logické a hlavně jednoduché na pochopení včetně blbuvzdorného příznaku isReleased
• Když obsluhu vzájemných stavů mezi třídami (přesun předmětu mezi hráči) nenajdu v první třídě, tak ji prostě najdu v té druhé a nemusím přemýšlet, jak byla před pěti roky pojmenována nějaká třetí a že vůbec existuje

@Tharos nepřijde mi vhodné vypínat auto generování proxy tříd, kdyby/doctrine to nastavuje imho velice příčetně. Pokud to chceš mít natvrdo vyplé, měl bys alespoň zmínit že se ty proxy třídy mají vygenerovat commandem (což je ale imho zbytečná komplikace a jednodušší je prostě nechat to ve výchozí autodetekci).

Moc se mi ale nelíbí řešení s isReleased. Chybou v implementaci modelu (někdo do toho bude rejpat) to můžeš dostat do nekonzistentního stavu.

Jedním řešením může být například, že vůbec nepoužiješ obousměrnou vazbu. Díky tomu půjde drasticky zjednodušit metoda changeOwner

public function changeOwner(Player $player)
{
    $this->owner = $player;
}

Jediná nevýhoda tohohle přístupu dříve byla, že když jsi psal DQL, tak doctrina ti nedovolila s tím pořádně pracovat. Dnes už ale můžeš v pohodě filtrovat i pomocí entit na které nemáš relaci.

$em->createQueryBuilder()
    ->select('p')->from(Player::class)
    ->innerJoin(Item::class, 'i', Join::WITH, 'i.owner = p')
	// ...

Připravíš se tím o možnost zavolat $player->getItems(), ale pořád nad tím můžeš přemýšlet jakože máš někde pole těch věcí a vždy si je vyfiltruješ podle ownera

$items = $itemsRepository->findBy(['owner' => $player]);

a to že ti je filtruje repozitář už je implementační detail, protože stejně dobře můžeš udělat

$allItems = new ArrayCollection([
	(new Item)->changeOwner($player1),
	(new Item)->changeOwner($player1),
	(new Item)->changeOwner($player1),
	(new Item)->changeOwner($player2),
]);

$items = $allItems->filter(function ($i) use ($player1) {
	return $i->owner === $player1;
});

// nebo
$items = $allItems->matching(
		Criteria::create()->andWhere(Criteria::expr()->eq('owner', $player))
);

Moc pěkná ukázka, Tharosi, moc díky. Asi se kouknu po nějakém ORM, možná Doctrine, nebo tvůj Lean mapper bude pro začátek lepší, co myslíš? Pokud je stále aktuální.

Děkuji za odkazy. Asi se pokusím podívat na Doctrine, ale určitě to pro začátek jednoduché nebude. Máš nějakou zkušenost s RedBeanPHP?

Zkusím se tedy podívat na Doctrine 2. Projekt dělám už docela dlouho a je tam napsaných spousta řádků a nezbývá mi příliš času na dokončení. Teď nevím, zda to zkusit přepsat a dokončit s Doctrine (určitě je riziko, že bych si to ještě víc rozbil :D, a s tím časem to opravu nevidím moc dobře), nebo dokončit a případně to zkusit přepsat, až to bude hotové.

A mohl bys mi, nebo kdokoliv jiný, ještě poradit, v čem dělají začátečníci v Doctrine nejčastěji chyby? Jinými slovy, na co si v začátcích dát pozor?

Jinak moc děkuji za všechny rady!

Ten článek na Zdrojáku je dobrý, z mého pohledu rozhodně lepší, než ten pětivrstvý model od Honzy Tichého. Na rozdíl od něj se totiž problémem anemického modelu alespoň okrajově zabývá.

Častým problémem těchto článků je, že se v nich řeší tak triviální zadání (blog za 5 minut, což je nejjednodušší možný CRUD), že tam z podstaty věci není možné ukázat nic pokročilejšího z objektového návrhu, protože to tam prostě není zapotřebí.

Vím, že začátečník potřebuje alespoň nějaké opěrné body. Představ si třeba krajní extrémy a zaměř se na to, proč jsou nevýhodné.

Pokud bys veškerou logiku řešil v entitách, stávaly by se Ti z nich snadno „God objekty“, určitě by měly spoustu zodpovědností a hlavně by musely vědět o vrstvách a částech aplikace, o kterých je zbytečné, aby vůbec věděly (prezentační vrstva, persistentní vrstva…). Zkrátka měl bys nezdravě vysokou míru provázanosti systému. To typicky zhoršuje refaktoring, ale i třeba znovupoužitelnost jednotlivých částí systému. Zkrátka přináší to samé nevýhody. Také bys narazil na potřebu injektovat do entit řadu služeb, což je skoro vždycky code smell.

Opačný krajní extrém je anemický model. Z entit si uděláš jen přepravky na data a veškerý „business“ (OK, s výjimkou pár validací) řešíš ve službách, které s těmi entitami pracují. Jak již bylo řečeno, tohle je sice funkční, ale suboptimální. V podstatě to jde proti jedné ze základích myšlenek OOP (spojit v objektech data a chování) a Ty tak z OOP netěžíš naplno jeho výhody. Je to takový odklon k procedurálnímu programování. Občas tomu někdo říká pejorativně třídní programování, čímž má na myslí, že sice používáš ve svých zdrojácích klíčové slovo class, ale neprogramuješ objektově. :) Tenhle styl má spoustu symptomů. Například to, že úplně na každou property v entitách potřebuješ getter a setter. To je logické, protože když ono chování přesouváš mimo objekty, potřebuješ mimo ně dostat i jejich stav, aby s ním ta servisní vrstva pak mohla pracovat. Při čistokrevném OOP naopak zjistíš, že řadu getterů a setterů v public API objektů vůbec nepotřebuješ (tím Tě ale nechci navádět k dalšímu extrému, kterým je princip tell, don't ask).

Jak je asi zřejmé, ideál je někde mezi. Jak rozhodovat, co kam patří? Snaž se umisťovat chování co nejblíže k datům (stavu). Pak bude OOP hrát ve Tvůj prospěch a Tvá aplikace se bude sestávat z hezky zapouzdřených, smysl dávajících objektů. Na druhou stranu si, zejména v entitách, hlídej, aby sis systém příliš neprovazoval. Máš-li například takovou logiku v entitě, která operuje jen nad jejím stavem, je to naprosto OK. Máš-li takovou logiku, která volá metody entit, s nimiž je v asociaci (vzájemném vztahu), je to také OK. To proto, protože některé entity zkrátka tak jako tak ví jedna o druhé a pořád je nejvýhodnější tohle volání provést „pod pokličkou“, než ho vynést úplně mimo ty objekty (viz třeba ta má RPG ukázka). Máš-li takovou logiku, která zpoza entity pracuje se šablonou, už to zavání. Zvaž, jestli je nutné, aby entita vůbec věděla o nějaké prezentační vrstvě a jestli by to celé nešlo vyřešit nějak lépe (pravděpodobně ano).

Dobrým pomocníkem jsou eventy, dokáží to provázání elegantně uvolnit (viz třeba uvolnění vztahu mezi entitami a nějaký messengerem v té RPG ukázce).

Editoval Tharos (17. 3. 2015 9:32)

@FilipKlimeš U entit ji máme v podstatě jenom na pár místech kvůli single table inheritance.

Dědičnost se nám obecně osvědčuje všude tam, kde jde o specializaci, a hodně s ní bojujeme všude tam, kde jde jen o hack, jak sdílet mezi třídami nějakou funkconalitu. :) Bohužel máme pár takových legacy míst, třeba občas někde „zprasenou“ hierarchii presenterů… V entitách naštěstí ne.

Proč chceš znásilňovat entitu user pro něco, na co není určena (zjišťování jestli je uživatel přihlášen)?

Nemusí být jenom hloupá přepravka na data, ale měl by mít spíše něco takového:

class User
{
	private $roles = [];

	public function __construct($roles)
	{
		$this->roles = $roles;
	}

	public function isAdmin()
	{
		return in_array("admin", $this->roles, TRUE);
	}
}

ved sablona uz obsahuje Nette\Security\User $user premennu. tak ju pouzi. a nevymyslaj sialenosti

IMHO to, že šablona (a presenter) už automaticky obsahuje proměnnou $user je jeden z nejvíc WTF momentů Nette. Je to název důležité entity každého většího systému s jakýmkoliv ORM a zdroj chyb typu:

{foreach $users as $user}
… <!-- výpis stejný, jako u všech ostatních entit - nic podezřelého -->
{/foreach}

…

{if $user->isLoggedIn()} <!-- WTF? proč to nefunguje jako všude jinde? -->

Editoval Šaman (22. 3. 2015 22:47)

@Tharos Super vysvětlení, jako vždy! Moc děkuji