NetteDatabase vs. Doctrine – klady zapory, zkusenosti

Ahoj, teďka začínám v jednom projektu pracovat s Doctrine. Předtím jsem používál výhradně NDBT. Ještě jsem přemýšlel nad Nextras\ORM. Hlavní důvod pro Doctrine bylo pro mě, že Nextras nemá žádnou dokumentaci. Doctrine má dokumentaci a téměř cokoli je buď tam nebo na stackOverflow.

Zatím jsem se k ničemu velkýmu nedostal, ale práce s entitama mě přijde naprosto boží. A práce s n:m tabulkama je taky skvělá. Spolu s Kdby/Doctrine je to skvělej nástroj.

Někde jsem četl, že pokud máš aspoň jednou m:n, tak se ORM vyplatí a musím to potvrdit.

Uvidím na konci projektu, jestli budu mluvit stejně :-)

Zax napsal(a):

Osobně bych NDB použil jen na opravdu malé projekty, kde nehrozí nějaké rozšiřování. Jakmile je v projektu potřeba ukládat strom, tak už bych to řešil jedině přes Doctrine, protože udělat (správně) strom v NDB včetně manipulace není zrovna triviální záležitost.

Když mluvíš o tom stromu, tak ten mam implementovaný pro Dibi a ano, nebyla to zrovna triviální záležitost :D

S Doctrine mám dobré skúsenosti, už pri práci so Symfony2. Ten systém entít je naozaj dobrý, takisto to automaticky generuje getters & setters a pri doctrine:schema:update to aj generuje automaticky foreign keys aby bolo všetko prepojené tak, ako to má byť. Pokiaľ sa pamätám, menšou nevýhodou je práca s indexmi (keď chceš vyhľadávať), vraj to v základe neponúka.

Já jsem s doctrine 2 začal před několika týdny. Zezačátku to byl boj, peklo, porod (doplňte další slova), ale jakmile jsem se naučil, jak pracovat s dědičností a asociacemi, tak to jde jako po másle a je to strašně pohodlné.

Filip Procházka napsal(a):

Doctrine je vlastně strašně jednoduchej nástroj, který ale nemůžeš používat bez toho, abys chápal koncepty na kterých je postavená. Pokud se tedy naučíš OOP (nebo se ho aspoň naučíš používáním Doctrine) a těch X vzorů které jsou kolem Doctrine a na kterých stojí, tak ten zbytek už je brnkačka.

Jaké vzory máš na mysli? Já žádné nepoužívám a dost možná je to chyba. Máš na mysli návrhové vzory? A jaké jsou kolem Doctrine?

Tharos napsal(a):

Aby to ale nebyla slova do větru, uvedu hned jeden příklad. Doktrína, jak je známo, není úplně nejrychlejší. Je to tím, že hydratace entit pomocí reflexe je (oproti Javě) opravdu strašně pomalá. Nastavit nějakou položku pomocí reflexe je cca o řád pomalejší, než pomocí setteru. No a když se pak dostaneš do úzkých (což se dostaneš u většího projektu velmi brzy), zkušení Ti poradí hydratovat data do polí namísto do objektů. Jenomže máš-li v duchu DDD spoustu logiky právě v těch objektech, máš v podstatě neřešitelný problém.

Hmm to by mě zajímalo, nakolik je toto pravda.. odkazovaný článek naopak píše, že Doctrine není pomalá, pokud si ji správně nakonfiguruješ (query cache, metadata cache, automatické generování proxy tříd, třeba i result cache pro selecty). Navíc třeba ta result cache, pokud se nepletu, hydratuje jen po invalidaci a jinak tahá rovnou hydratovaná data z cache (přiznám se, že úplně nevím, jak moc košér je zapínat tuto cache na prakticky všechny selecty kromě dat, která se často mění, ale zatím jsem nenarazil na problém).

Zax napsal(a):
Hmm to by mě zajímalo, nakolik je toto pravda.. odkazovaný článek naopak píše, že Doctrine není pomalá, pokud si ji správně nakonfiguruješ (query cache, metadata cache, automatické generování proxy tříd, třeba i result cache pro selecty).

Já jsem na tenhle článek odkázal schválně, protože přesvědčování, že Doctrine není pomalá, v něm vypadá tak, že Ondřej popisuje, jaké všechny cache si kde pozapínat, aby nebyla pomalá. :) Takže ano, Doktrína je pomalá, ale existují na to náplasti. Některé vhodné více (cache), některé pro mě osobně méně (array hydratace).

Abych ještě dokreslil ty problémy s array hydratací… Není to dokonce jen o logice, která se v entitách může nacházet, ale i o tom, že entita nahydratovaná do pole neprojde žádným typehintem, který očekává entitu, takže na řadě míst aplikace může vznikat polymorfismus, který řeší, jestli dostal entitu Author nebo pole, které obsahuje informace o autorovi atp.

Rada, aby se na produkci vypnulo generování proxy tříd při každém requestu, mě až pobavila. Kdo si nechává na produkci při každém requestu generovat proxy třídy? Pro nezasvěcené je to podobné, jako kdybyste si na produkčním serveru při každém requestu nechali přegenerovat Nette DI kontejner.

Navíc třeba ta result cache, pokud se nepletu, hydratuje jen po invalidaci a jinak tahá rovnou hydratovaná data z cache (přiznám se, že úplně nevím, jak moc košér je zapínat tuto cache na prakticky všechny selecty kromě dat, která se často mění, ale zatím jsem nenarazil na problém).

A co když mám takovou entitu, kterou není možné z nějakého důvodu serializovat? Jak vůbec ta cache funguje, tzn. v jaké podobě a co přesně ukládá? Ptám se, jestli mi něco neuniká – rád svůj postoj případně přehodnotím!

@FilipProcházka korektni by bylo zminit, ze to vyzaduje redis, memcache, nebo apc(u), coz moc casto na hostingu nenajdes ;-)

@hrach když tvá aplikace potřebuje L2 cache tak bych se nebál tvrdit, že už nemáš úplně malou aplikaci a tedy stojí za zvážení VPS, případně ne-sračkoidní hosting.

Entity v Doctrině jsou serializovatelné, protože jde jen o hloupé obálky, člověk se musí snažit a cpát tam nějaký resource aby entita nešla serializovat.

@Zax To není tak úplně pravda, pokud máš v relacích nějakou proxy nebo kolekci, tak ty mají reference na Connection a to už tak snadno nezeserializuješ.

Ovšem to se dá strašně snadno vyřešit napsáním metody __sleep() nebo použitím jiného mechanismu. Navíc BaseEntity v Kdyby za tebe polovinu problému (to co bys měl všude stejně) už řeší.

Aké väzby máš na mysli? Ak nechceš aby nejaká entita nebola zmapovaná a vložená do DB, nepoužiješ anotáciu @ORM. Teraz neviem, či za entitu pokladáš celú tabuľku alebo len nejaký stĺpec.

Editoval Lkopo (21. 9. 2014 17:11)

Btw a co takové spojení doctrine a couche? Když jsem se podílel na jednom projektu tak tam tohle spojení bylo. Pravda, přináší to pár komplikací ale zase to bylo vyváženo rychlou odezvou data které se netahaly z mysql ale právě z couche.

@Šaman ještě to takto děla Nextras\ORM (ta nezavislost entit).

@FilipProcházka ale on tu nikdo nemluvil o velkych projektech, naopak se tu mluvilo o malych projektech, na ktery je Doctrine moc velka a pomala.

Právě na to ukládání objektů kamkoliv jinam, než do relační db. Ale to už opouštíme běžný model práce. Nerelační databáze, ukládání na disk (třeba objekt s nastavením uživatele mít v session a nemuset ho vždy vytvářet znovu), nebo dokonce předávání objektů mezi dvěma samostatnými částmi aplikace po síti, pokud každá běží na jiném stroji.

Pardon, zavzpomínal jsem si na pár teoretických přednášek ze studií. Na podobné věci by použil PHP jenom masochista. :D

@hrach napsal(a):

@FilipProcházka ale on tu nikdo nemluvil o velkych projektech, naopak se tu mluvilo o malych projektech, na ktery je Doctrine moc velka a pomala.

S tím právě nesouhlasím a myslím si že jde hlavně o efektivitu vývoje (která je v mém případě NDTB vs Doctrine nesrovnatelná). U malých projektů je maličko pomalejší web ten nejmenší problém.

@Zax napsal(a):

Pro mě entita = objekt obsahující data z databáze a nečekám od toho nic víc, než že mi předá data z databáze. Co se má s těmi daty dělat už entitu zajímat nemusí.

Tomuhle se říká Anémický doménový model a já i pan Fowler si myslíme, že to není úplně nejlepší :) Na malých projektech kde prostě tu logiku nemáš se nic neděje, ale na velkých projektech alespoň nějakou logiku v entitách potřebuješ, jinak je ti ORM nahouby a můžeš jít dělat třeba v AR, nebo čisté NDBT :)

Stejně tak jako entita neví nic o tom, kam jsou její data ukládána, nevidím důvod, proč by měla vědět o té „druhé straně“ – tedy o tom, co s těmi daty potřebuje dělat aplikace. Čistě můj názor.

To že se Entita neví jak je ukládána je přednost, jenže Entita je součástí doménového modelu a tedy bych jí úplně nebránil tušit na co její data budou použita. Například taková entita uživatele vůbec nikomu nemusí říkat ani hash hesla. Když chceš ověřit přihlášení, zeptáš se entity

	public function verifyPassword($password)
	{
		return Passwords::verify($password, $this->password);
	}

	public function changePassword($password = NULL, $oldPassword = NULL)
	{
		if ($oldPassword !== NULL && !$this->verifyPassword($oldPassword)) {
			throw new Nette\Security\AuthenticationException("The old password doesn't match");
		}

		$this->password = Passwords::hash($password);
		return $this;
	}

Neříkám že tohle je ten nejlepší způsob jak to vyřešit, ale je to naprosto validní způsob jak to vyřešit. Hash se stal implementačním detailem entity uživatele a už není anémická :)

protože minimálně entity, které nejsou proxy, by měly jít cachovat naprosto bez problémů

Technicky vzato, i ty proxyny jdou cachovat bez problémů, jenom si musíš implementovat vlastní __sleep, což je primitivní :)

@Tharos napsal(a):

Pokud ale očekáváš víc, jako například možnost mít bohaté doménové objekty ve stylu DDD, buď připraven na to, že s Doktrínou velmi snadno narazíš.

Tohle bych prosil rozvést, protože nesouhlasím :)

Komu by se nelíbila implementace a práce se statickým prostorem, ať se pro zajímavost podívá, co vše si do statického prostoru ukládá Doktrína. :-P

Jenom typy db fieldů, které jsou bezkontextové, takže je to jedno :)

Zax napsal(a):

Co když ale nějaká logika v entitě vyžaduje nějakou službu? Mám si ji ručně předávat při každém volání té logiky? Mám nějak znásilnit Doctrinu, aby mi tu službu nějak automaticky injectovala? Nebo mám prostě copy&pastnout kód z té služby do entity?

tak tam mas nieco zle

Zax napsal(a):
Co když ale nějaká logika v entitě vyžaduje nějakou službu? Mám si ji ručně předávat při každém volání té logiky? Mám nějak znásilnit Doctrinu, aby mi tu službu nějak automaticky injectovala? Nebo mám prostě copy&pastnout kód z té služby do entity?

Koukám že zmatení a buzzwordizace kolem DDD dosáhly lokálního maxima. Pokud máme na mysli entitu z DDD tak jejím úkolem (resp. úkolem agregátu) je udržovat vnitřní konzistenci (definovat sadu invariantů které zachovává). Např. „nezaregistrovanému zákazníkovi nelze změnit heslo“ nebo „odeslanou fakturu nelze upravovat“.

Pro ilustraci uvedu typický případ porušení tohoto principu – dejme tomu že vytvářím nějakou objednávku obsahující jednu položku:

$order = new Order();
$order->addItem($item);

Takhle to určitě dělá spousta lidí a přitom hned na prvním řádku je problém – objednávka s nula položkami nedává smysl, správně by mělo být něco jako $order = new Order($customer, $items);.

Teď když si rozumíme tak k tomu „injektování služeb do entit“. Záleží co se myslí tou službou, pokud „service“ z DDD, tak viz níže, já mám ale podezření že @Tharos myslí klasický případ typu „při potvrzení objednávky potřebujeme poslat email“. To samozřejme nemá v entitě co dělat, protože to jestli se email odeslal nebo ne nijak nesouvisí s konzistencí té entity. Dá se na to dobře použít event sourcing, případně staré dobré „services“ z DDD.

Služby v DDD se totiž neinjektují do agregátů (tím méně do entit), ale naopak do služeb se injektuje repozitář, ze kterého se potřebný agregát vytáhne.

// ConfirmOrderService:
public function confirmOrder($orderId)
{
	$order = $this->repository->getById($orderId); // throws AggregateNotFoundException
	$order->confirm();
	$this->confirmationMailer->sendEmail($order); // tady použijte kdyby/events :-)
}

Přičemž $this->confirmationMailer není „service“ podle terminologie DDD.

Jako jedna z výjimek kdy je potřeba nějaký objekt dostat do entity je strategy pattern, ale tam bych daný objekt předávál jen do konkrétní metody která ho potřebuje. Např. při potvrzování té objednávky bychom molhli potřebovat vygenerovat číslo objednávky:

public function confirm(IOrderNumberStrategy $strategy)
{
	$this->confirmed = true;
	$this->number = new OrderNumber($strategy->generateNumber());
}

BTW: rád bych si na posobotě pokecal s někým kdo si myslí že dělá DDD, přečetl aspoň „modrou knížku“ od Evanse a nějaký čas nad tím přemýšlel. Já mám zatím pocit že to všichni okolo mě dělají blbě (což může dost dobře znamenat že to dělám blbě já).

K tomu mám dva poměrně silné názory:

• pokud pracujete s entitou v presenteru (nedej bože v šabloně) tak to děláte blbě:

  Mimo modelovou vrstvu se pracuje s identifikátory a view/DTO objekty. Pomocí nich se komunikuje se „services“ a „repositories“.

• pokud používáte Kdyby\Doctrine\Entities\BaseEntity tak to děláte blbě:

  Settery jsou zlo a pokud vám je entita magicky generuje tak vás bude svádět je používat.

PS: DDD mnohem víc řeší jak máte komunikovat se zadavatelem, než jak máte programovat. Třeba takový „ubiquitous language“ považuju za mnohem důležitější princip než cokoliv co vyčtete z kódu. Takže to berte s rezervou.

Editoval mkoubik (24. 9. 2014 11:40)

@mkoubik doufám že se konečně potkáme na této posobotě a nezapomeneme (zase) si o tomhle pokecat :)

@mkoubik: Díky za výborné příspěvky!

Nedalo mi to a trochu jsem se dovzdělal. Zjistil jsem, že mezi programátory existuje velké zmatení pojmů (a dojmů) a že (Rich) Domain Model (tak, jak je popisuje například Fowler) !== DDD (tak, jak jej popisuješ Ty a Evans).

Celá část Domain Model z PoEAA je shodou okolností dostupná online, takže tu už nemusím nic obšírně popisovat. Chtěl bych ale opravit svá zdejší tvrzení, protože kde jsem psal DDD, myslel jsem Domain Model.

V něm je injektování služeb do entit IMHO legitimní. Hezká ukázka je už v odkázaném článku. Podívej se třeba na třídu Product:

class Product...

   private String name;
   private RecognitionStrategy recognitionStrategy;
   public Product(String name, RecognitionStrategy recognitionStrategy) {
      this.name = name;
      this.recognitionStrategy = recognitionStrategy;
   }
   public static Product newWordProcessor(String name) {
      return new Product(name, new CompleteRecognitionStrategy());
   }
   public static Product newSpreadsheet(String name) {
      return new Product(name, new ThreeWayRecognitionStrategy(60, 90));
   }
   public static Product newDatabase(String name) {
      return new Product(name, new ThreeWayRecognitionStrategy(30, 60));
   }

Pokud bych vytvářel produkt přímo (konstruktor je public), určitě bych tam RecognitionStrategy injektnul. Co je ale důležité je, že Product má asociaci k RecognitionStrategy, ví o ní a vyžaduje ji ke své práci.

Mohli bychom celou tu logiku vyhodit z entity do nějaké servisní vrstvy, ale to je právě přechod od Rich Domain Modelu k anémickému modelu, který se z velmi rozumných důvodů nedoporučuje.

Překvapuje mě, jak se Domain Model a DDD zjevně liší, ale nejsem odborník ani na jedno. Jen ve svých aplikacích čím dál více sleduji, že tíhnu k něčemu, co Fowler popisuje jako Rich Domain Model, a velmi se mi to osvědčuje.

To injektování závislostí v Lean Mapperu je shodou okolností právě úplně triviální, stačí mít takovouto EntityFactory:

class EntityFactory extends DefaultEntityFactory
{

	/** @var Container */
	private $container;


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

	/*
	 * @inheritdoc
	 */
	public function createEntity($entityClass, $arg = null)
	{
		return $this->container->createInstance($entityClass, ['arg' => $arg]);
	}

}

Pak lze mít například entitu:

/**
 * @property int $id
 * @property float $price // see getPrice
 * ...
 */
class Product extends Entity
{

	/** @var CurrencyConverter */
	private $currencyConverter;


	/**
	 * @param CurrencyConverter $currencyConverter
	 * @param mixed $arg
	 */
	public function __construct(CurrencyConverter $currencyConverter, $arg = null)
	{
		$this->currencyConverter = $currencyConverter;
		parent::__construct($arg);
	}

	/**
	 * @param string|null $currency
	 * @return float
	 */
	public function getPrice($currency = null)
	{
		$price = $this->get('price');
		return $currency === null ? $price : $this->currencyConverter->convert($price, $currency);
	}

}

Editoval Tharos (30. 9. 2014 21:20)

akadlec napsal(a):

@mkoubik pls můžeš tohle trochu rozvést?

pokud pracujete s entitou v presenteru (nedej bože v šabloně) tak to děláte blbě:

Mimo modelovou vrstvu se pracuje s identifikátory a view/DTO objekty. Pomocí nich se komunikuje se „services“ a „repositories“.

Ano, to by bylo velmi dobré rozvést. Co konkrétně je práce? Já například z entity v šabloně i presenteru čtu a vůbec se za to nestydím. Dělám to dobře nebo se nemá z entity ani číst?
Ovšem změny properties nechávám na modelu.

Načítání dat z entit:

Já na to používám nějaké view-model objekty, které jsou (většinou) specifické pro danou šablonu a je jedno odkud se do té šablony dostanou. Může je třeba používat kodér pro jednoduché nasypání testovacích dat do šablony (třeba z neonu). Daly by se tím ty šablony testovat (i když to je asi blbost). Zkrátka to hezky definuje rozhraní mezi presenterem a šablonou.

Tyhle objekty pak vytahuju ze specializovaných repositories (které jsou většinou jednoduché a jen to mapují z entit). Výhoda je, že kodér může jakkoliv pracovat s daty v tom objektu (vnořené/opakované cykly, procházení vazeb, …) aniž by se bál o výkon. Jak efektivně všechno vytáhnout z db zase řeším já.

Ale je fakt, že u menších aplikací, nebo tam kde až tak nezáleží na izolaci šablon (různé „themes“, „skiny“ apod.) se dá ta entita použít i v šablonách (zvlášť pokud je píše programátor).

V Symfony je zvykem používat naopak hloupé předgenerované entity (gettery a settery) a pak musíš používat sandboxmode Twigu pokud chceš omezit co se dá s entitama v šabloně dělat.

Úprava dat

Tady je zase dobré mít nějakou doménovou vrstvu (zvlášť pro každou „doménu“) izolovanou (takže testovatelnou) od zbytku aplikace. To že ta vrstva používá doctrine a nějaké entity je zase implementační detail.

Já chci napsat něco jako $this->orderProcess->confirmOrder($orderId) a chci aby daná služba udělala co potřebuju, případně vyhodila výjimku.

Tohle je nejjednodušší možné api, proč bych měl řešit jaký objekt použít jako parametr a kde ho vzít, když stačí nějaký unikátní identifikátor?

Editoval mkoubik (1. 10. 2014 9:40)