Rich domain model vs. select z DB

Upozornění: Tohle vlákno je hodně staré a informace nemusí být platné pro současné Nette.
před 10 lety
Filip Klimeš
Nette Blogger | 156
+
0
-

Řeším takový folozofický problém..

mám rád ORM a rád píšu logiku do entity v rámci rich domain model. Ale občas se mi ta logika, mrška, duplikuje v repozitáři při výběru entit z DB.

Dám příklad – mám u nás na StartupJobs entitu Offer (nabídka práce), která o sobě umí říct, jestli je aktivní $offer->isActive(). Problém je, když takovéhle nabídky chci vybrat z DB. Musím tu samou logiku mít v QueryObjectu, který tím pádem musí znát vnitřní strukturu Entity, což je fuj na mnoha úrovních.

Jak to řešíte vy?

před 10 lety
jakub.barta
Člen | 10
+
0
-

Smiril jsem se s tim, ze QueryObject bude znat vnitrni strukturu entit. Jedine teoreticke reseni, ktere je ale v praxi nepouzitelne, je natahnout z DB vsechny a pak filtrovat podle vysledku $offer->isActive().

před 10 lety
Filip Klimeš
Nette Blogger | 156
+
0
-

Jj, to mě taky napadlo, ale bohužel to v praxi moc často nejde.

před 10 lety
Šaman
Člen | 2668
+
0
-

Tohle je dilema všech ORM – IMHO základní problém modelu, proto neexistuje ultimátní ORM. Buď se bude bližit jednomu, nebo druhému, nebo zkusí nabídnout obě strategie a pak je to moloch (Doctrine) a programátor si stejně musí vybrat. Ještě větší problém je vybírat entity podle vlastností, u kterých se jednoduše do db zeptat nedá. Třeba geometrické obrazce podle obsahu. Každá entita si umí spočítat obsah, ale pokaždé to bude jiný výpočet (kruh, čtverec) a často z více sloupců (obdélník). Pak už se na některé práce hodí i jiná úložiště, než relační databáze…

před 10 lety
Filip Procházka
Moderator | 4668
+
0
-

“Duplication is far cheaper than the wrong abstraction.” via @bonzoesc

Nevidím v tom zásadní problém. V momentě kdy to máš jen na dvou místech, tak je to úplně v pořádku udržitelné. Od toho jsou fajn QO, kde můžeš pro entitu mít 30 metod na různý podmínky a pak si to jen poskládáš.

Nevzpomenu si kdo, ale někdo mi říkal, že dělá bakalářku na přesně tohle téma. Že by nějak poznal z metody co vlastně dělá a umožnil ji použít v DQL. Samozřejmě nic extrémího, jen základní věci. Ale i tak by to na některé ty is*() metody bylo pěkné :)

před 10 lety
newPOPE
Člen | 648
+
0
-

Kasli na to. @FilipProcházka ma pravdu. Ked si vezmes take CQRS tak ono ma read a write modely cize hned vychadza ze to musis mat na 2och miestach.

Ja osobne som toho nazoru ze tak alebo onak (ci mas Doctrine alebo Nette\DB) je stale vsetka struktura v DB. To je fakt a zatial ma ziadna ina myslienka okolo toho nenapadla. Ked mas Doctrine alebo ORM tak dostanes par veci naviac ale stale vsetko (struktura, data, relacie, …) v DB. Cize DB je odrazovy mostik celeho modelu.

Editoval newPOPE (1. 7. 2015 8:53)

před 10 lety
mkoubik
Člen | 728
+
+2
-

Doménový model (entity, agregáty, …) bys ideálně měl používat jen pro změnu stavu aplikace. V DDD se pro čtení většinou používá nějaký read-model (googli CQRS), ve kterém máš jen ta data, která potřebuješ pro dané view (nebo skupinu views) a tam máš přímo sloupeček active podle kterého to selectuješ.

Buď ho můžeš generovat přímo z těch entit (cacheovat do tabulky/elasticu) a invalidovat při každé změně, nebo může ta entita generovat nějaké události offerActivated(id) a offer deactivated(id) a podle nich to přepínat.

před 10 lety
Filip Klimeš
Nette Blogger | 156
+
0
-

To s tím cachováním do elasticu se mi vážně líbí! Díky za nápad :)

Prostudoval jsem CQRS přímo od Fowlera, zajmavý, takovýmu modelu se snažim blížit a ani nevím, že existuje.

před 10 lety
Filip Klimeš
Nette Blogger | 156
+
0
-

Souhlasím, že je jednodušší to mít na dvou místech a dá se to poměrně dobře udržet. Ideální to ale není.

Právě jsem narazil na zajmavej článek o DRY. Podle toho je isActive() jedna „znalost/knowledge“, takže porušuju princip.

Editoval Filip Klimeš (1. 7. 2015 21:08)