Chytré Entity s inject – skze injected factory?

Musí to být určitě metoda té entity?

Neměla by entita jen přenášet data a obstarávat jednoduché operace s nimi (konverze, validace)?

Proč nepoužít

class ProfilePresenter extends BasePresenter
{

    function renderXy() {
        $this->template->userProducts = $this->productService->fetchByUser($this->user->id);
    }


}

Entita sama o sobe by mela byt celkem hloupa a resit maximalne validaci dat. Pouzij IMHO bud DAO nebo Service.

Nedávno jsme řešili něco podobného a skončili jsme s takovýmhle řešením.

Máme service EntityFactory:

<?php
class EntityFactory {

  /** @var \Nette\DI\Container */
  protected $container;

  /**
   * @param Container $container Container from which injects is called
   */
  public function __construct(Container $container) {
    $this->container = $container;
  }

  /**
   * Create new Entity instance and injects all Dao objects
   * @param string $className Entity class
   * @return BaseEntity
   */
  public function create($className) {
    $entity = new $className();
    $this->container->callInjects($entity);
    return $entity;
  }

}
?>

Máme vlastní vrstvu DAO (repository), která nevrací výsledky jako instance pod ní umístěného ORM, ale jako naše Entity, nebo EntityCollection. Prostě konkrétní implementace repository použije nějaké ORM, cache, vzdálené volání, apod. a výsledek převedena na Entity z doménového modelu. To dělá tak, že má injectnutou EntityFactory a převádí tak všechno na naše Entity, které dostanou injectnuté další závislosti.

Felix: Entity by rozhodně neměla být jen obálka na data. Viz anti-pattern https://en.wikipedia.org/…domain_model

Editoval mystik (30. 10. 2013 8:24)

Casper napsal(a):

@mystik:

Tohle řešení jsem chtěl také realizovat (nad LeanMapperem, s použitím generovaných továrniček), ačkoliv zde určitě najdeš odpůrce, kteří ti řeknou, že entita si nemá co vyžadovat nějaké závislosti :) Nicméně může nastat problém, pokud k vytváření entit nedochází jen v Repository, což je právě případ LeanMapperu. Aneb musí tvé ORM podporovat vytváření entit pomocí nějakých továrniček.

No jaké jiné vytváření máš na mysli? Napadají mě 2 možnosti:

1. Lazy kolekce – ty máme řešené vazbou na Repository. Tj. repository vrátí kolekci, které je schopná si z repository data donačítat lazy. Samozřejmě že tohle je před uživatelem té kolekce skryté. Kolekce je jen interface a každá repository si sama řeší jak vypadá její implementace pro ni.
2. Vytváření nové Entity – to máme řešené tak, že prostě entitu vytvoříš klasicky konstruktorem. Takhle volně vytvořená entity ale nemá žádné vazby – podle mě by ani mít neměla dokud není persistované přes repository. Takže snaha o použití jejich metod, které používají injectnuté věci vyhodí exception, že je ji nutné nejdříve persistovat.

@mystik

LeanMapper má trochu netradiční filozofii ORM k dosažení určitých cílů, takže související vazební entity vytváří i v entitách (vnitřně). Díky tomu umožňuje pokládat konstatní počet dotazů jako NotORM a snadno traverzovat přes vazební entity.

K dosažení toho co říkáš ty bych musel do LM sahat tak, aby se kontejner předával mezi repository a entitami při jejich vytváření (možná si to někdy forknu a zkusím).

Casper napsal(a):

@mystik

LeanMapper má trochu netradiční filozofii ORM k dosažení určitých cílů, takže související vazební entity vytváří i v entitách (vnitřně). Díky tomu umožňuje pokládat konstatní počet dotazů jako NotORM a snadno traverzovat přes vazební entity.

K dosažení toho co říkáš ty bych musel do LM sahat tak, aby se kontejner předával mezi repository a entitami při jejich vytváření (možná si to někdy forknu a zkusím).

No my v entitách to řešíme tak, že tyhle related věci stejně vždycky načítáme přes repository. Má to svoje důvody, protože u projektů, kterej řešíme se dá očekávat, že tam bude více než jeden způsob perzistence. V zásadě ale jde o to, že my v entitě máme něco jako:

<?php
  public function getMainAdministrator() {
    return $this->getUserDao()->fetchMainAdministratorOfEvent($this);
  }
?>

O to položení related dotazu a podobně se pak už stará UserDao a ven dostaneš kolekci entit s injectnutýma závislostma. Interně to UserDao ale může fungovat stejně jako v LeanMapperu.

@Casper: Ten požadavek měla řada lidí :).

@mystik: Smím se zeptat, jak řešíte problém N+1? Klidně jenom nástřel řešení… Zkrátka jak postupujete v případě, že někdo iteruje nad více entitami a pro každou zavolá getMainAdministrator. Díky!

Editoval Tharos (30. 10. 2013 9:49)

@mystik:

Díky za odpověď. Pár věcí rozvedu:

Felix: Entity by rozhodně neměla být jen obálka na data. Viz anti-pattern https://en.wikipedia.org/…domain_model

Můj názor na tohle je takový, že to nelze paušálně říct. Povaha aplikace může být extrémně různá, viz ten knihovní IS vs. hra v mém příspěvku na Poslední sobotě.

Programujeme-li aplikaci s velmi strohou (až žádnou) doménovou logikou, třeba jenom nějaký CRUD, víceméně nepotřebujeme žádný model. Klidně můžeme klást dotazy přímo z presenterů a nikdy s tím nenarazíme na problém.

Programujeme-li aplikaci s velmi bohatou doménovou logikou (což ale IMHO webové aplikace většinou nebývají), pak je škoda skončit úplně s anémickým modelem, protože v tom kontextu může jít skutečně o anti-pattern. Prostě existuje lepší řešení.

Většina webových aplikací, jaké alespoň já programuji, je někde mezi. Nějakou doménovou logiku obsahují, ale není to nic závratného. Část doménové logiky v entitách ponechávám (validace, dopočty nějakých hodnot), část ji mám ve vrstvě nad těmi entitami. Takže v podstatě anemický model. No a nemám s tím žádný problém :–P. Má to své výhody a nevýhody, které jsem schopen vyjmenovat, a ty výhody mi zde převažují.

Všimni si, že to, zda je či není anemický model anti-pattern, se všemožně na netu horlivě diskutuje. Z toho je patrné, že to není tak černobílé. :) Mně se třeba moc líbí tenhle pohled na věc.

Myslím, že Ty tíhneš spíš k plnokrevnému doménovému modelu, zatímco Lean Mapper je lépe připravený na anémický model. Pokud máš opravdu tak košatou aplikaci, že výhody plnokrevného doménového modelu oceníš (anebo jej opravdu chceš), říkám otevřeně, že Ti bude možná lépe vyhovovat Doctrine 2 anebo úplně ruční O/R mapování – to bych v takovém případě možná volil já. Lean Mapper je prostě lean a taky ne úplně vše spásný.

Editoval Tharos (30. 10. 2013 10:52)

@Tharos:

Více méně souhlas. Pro jednoduché CRUD aplikace hloupé entity plně stačí. Vždycky je nutné uvažovat o nejvhodnějším nástroji pro daný účel.

Na druhou stranu dle mojí zkušenosti jsou častější webové aplikace, které nějakou business logiku obsahují. Ale to je asi tím na jakých projektech jsme pracovali.

Tohle rozhodně neměly být nějaká kritika LeanMapperu – popravdě to naše řešení se jím dost inspirovalo :-)

Rozhodně ale nemůžu souhlasit s tím, že Entity BY MĚLY být jen hloupé obálky na data. Podle mě by měly být chytré, ale s tím, že se z toho dá občas ustoupit. Hloupé entity totiž porušují některé principy, podle kterých pracuju s objektovým návrhem. Třeba information expert. Více viz třeba můj článek na zdrojáku http://www.zdrojak.cz/…t-a-creator/

Taky je mi bližší DDD – tj. začínat doménovými entitami a pak vyřešit jejich perzistenci a ne naopak.

To ale nevylučuje použití ORM typu LeanMapper. Jde ale o to, že entity a kolekce, se kterými pracuje doménová logika jsou naše vlastní typy obalující typy použitého ORM. Tj. Repository není ORM, ale Repository používá ORM.

Vy jste se teda rozjeli OT.

Můj dotaz: chytré entity snadno a rychle.

@mystik: To vypadá pro mě použitelně, díky. Repository vytváří ze záznamů entity na úrovni metod typu fetch() a fetchAll()? To už bych si dokázal představit.

@Tharos: Můžeš rozvést tu 2? Téma * modelů je mi cizí, používám BaseModel a to je vše.

@Schmutzka: Ad 2) Jde o tento přístup.

@Schmutzka: Hezkou a stručnou ukázku najdeš například zde.

@Schmutzka: Je to v podstatě tak. Ona ty věci ta entita sama nedělá, také je deleguje, ale dost věcí se realizuje skrze API entity.

Takto navržený model má své výhody (např. robustnost, plné využití potenciálu OOP…) i nevýhody (např. vyšší nároky na kvalitní návrh, vyšší nároky na ORM…).