Návrhový vzor pro entity při 5ti vrstvém modelu

Ahoj,
přiznám se, že jsem nečetl celý příspěvek, ale myslím, že pro začátek by mohla pomoci skvělá přednáška od Martina Štekla v PoSoboty

@CherryBoss > uaaa, nova prednaska, mrknu, diky.

@castamir > ono jsem to mozna nazval blbe, resp takto: nejde mi o kolekci vsech entit ale vzdy pouze o jednu jedinou entitu s tim, ze bude umet dohledat sveho predchudce/naslednika, cili bude mit poradi, ale neni to cela kolekce entit. Jako priklad uvedu treba MoznostVAnkete – je to BaseListEntity, jelikoz ma poradi v ramci vsech moznosti v ankete. Nebo PolozkaMenu – je to BaseTreeEntity, jelikoz ma uroven i poradi v ramci urovne. Atd. Takze tady uplne problem nemam, ale co kdybych prave chtel jednu polozku menu, ktera pujde aktivovat a jinou polozku menu ktera aktivovat nepujde (v ramci dvou ruznych entit!)? A idealne tak aby obe dedily primo od BaseTreeEntity a rovnez abych nemusel dopisovat implementaci pro tu aktivaci?

@castamir > zajímavé, zajímavé. Jen teď teda nevím jestli toto není další vrstva do 5ti vrstvého modelu a nebo to není service vrstva (nebo repository), která by něco takového taky mohla řešit. Pokud by to byla nová vrstva (ikdyž možná je označení vrstva trochu špatné) tak je to velmi zajímavý pohled. Co se mi ale na první pohled moc nelíbí je možnost se stejnou entitou pracovat různě. Jednou může být položka menu jako EntityTree jindy zase jako EntityCollection, což trochu znepřehledňuje a je to takový nekonzistentní, přece jenom pořád pracuju se stejnou třídou.

Nicméně tohle není úplně to na co sem se v tom původním příspěvku ptal. Problém s typy entit pořád přetrvává, protože pořád můžu mít entity aktivovatelný/přeložitelný/publikovatelný nebo ne a pořád si přes dědičnost nevystačím i když ty kolekce přesunu o úroveň výš. Proste mám nějakou entitu a jí řeknu: ty jsi seznam, lze tě aktivovat a máš lokalizaci a bum, můžu najednou nad entitou volat $entity->isActive(); nebo $entity->getSuccessor();. Možná jsem do toho ty seznamy a stromy neměl motat (ostatně je to vlastně totéž jako že je entita aktivovatelná) :-)

aha, ja mel vzdy za to ze tam entityCollection neni ale naopak tam je primo uloziste (DB, FS, whatever)… Viz PHP Guru. V tom je mozna ta chyba…

Editoval hAssassin (3. 4. 2013 18:11)

Přemýšlím, zda má vůbec smysl mít podobnou/stejnou logiku na jednom místě pro více různých entit. Nejsem totiž přesvědčen, že tato logika bude stejná pro všechny entity – kupříkladu aktivace článku a uživatele se bude skoro určitě nějak lišit :-) Tahle logika by měla být IMHO v service vrstvě.

Pokud ale neřešíš logiku, která nastaví nějaký „flag“, že entita je aktivní, ale řešíš samotné nastavení toho flagu, pak jsem jednoznačně proti nějakému spojování logiky do dekorátoru nebo čehokoli jiného. Jedná se v podstatě o jednořádkový (pro fluent interface dvouřádkový) setter. Ten lze sadno v každém rozumném IDE vygenerovat nebo můžeš používat __get/__set metody.

Webové frameworky jsme si všichni už napsali, tak teď si všichni napíšeme vlastní ORM. :-)

Pokud ti chybí vícenásobná dědičnost (traits), tak chceš, aby jedna třída uměla víc věcí. A to je skoro vždycky špatně.

Pořadí položky v seznamu není podle mě vlastností položky, ale seznamu. Může pak existovat služba, která ze seznamu abstrahuje práci s jednou položkou:

$listItem = new ListItem($list, $item);
$listItem->getItem(); // === $item
$listItem->isLast();
$listItem->getNext();
$listItem->getNext()->getNext()->getItem();
$listItem->getPrevious();
$listItem->shiftUp();
//apod.

Nevím, proč se bráníš tomu, aby entity byly pouhými obálkami nad daty. Pokud by entita měla být obálkou nad daty, překladačem textů, publikátorem článku a ještě správcem svého záznamu v nějakém seznamu, tak to už jsou čtyři různé odpovědnosti a k některým bude potřebovat další služby. Pro lokalizaci nejspíš bude entita potřebovat Translator, jak ho získá?

@hAssassin: Jeden ze způsobů, jak to vyřešit, je přes anotace třídy a magickou metodu __get(), ale já bych se tomu vyhnul.
I když je psaní/generování setIsPublished($val = true), isPublished() opruz, není to zase tolik psaní/generování aby to zastínilo výhody čistého a jasného kódu.
Traits jsou zajímavá myšlenka.

Editoval bene (4. 4. 2013 18:04)