JENIIK: a proc nemuzes misto triggeru pouzivat eventy v tridach?

LITTLELI: holt to (N)H musi umet clovek spravne pouzivat (jako ostatne vsechno) a dobre tu aplikaci nadesignovat. s tim lazy loadingem se vazne da udelat dost kixu..
ad anotace - to je jenom jeden zpusob - muzes mit nadefinovany mapovani i externe, pokud ti to ve zdrojacich prekazi. iBatis to ma tusim podobne, ne? ono nekde to mapovani definovany bejt musi... i kdyz asi by se dal napsat mechanismus, kterej by ti primo z trid vygeneroval mapovani + DB strukturu, ale to by asi nebylo uplne to pravy :)

BUTHRAKAUR: no a ta pomocná entita je pak co? jen soubor sql. Ty pomocná data stejně musíš sbírat triggerama (dobře, nemusíš, pokud nechceš používat transakce v sql, ale... ;-)) takže aplikační logiku máš stejně i v db. Ona pomocná entita je ta moje helper class. Takže objekt zakázky pak používáš k čemu?

Není to ani čisté, ani intuitivní, ani automatické, ani jednoduché... Nějak v tom nic nevidím...

Prostě data se sice tváří jako objekty, ale v momentě, kdy s nima začneš pracovat relačně, tak se ti víc hodí relační přístup. V momentě, kdy přestaneš pracovat fakt s jednotlivými objekty, dostaneš se do situace, kdy začneš celý objektový koncept ojebkávat a to je přesně to, co se mi nelíbí.

Objektový přístup k věci mám rád, ale spíš směrem k funkcionalitě, než k datům. Sám jsem kdysi u EJB jásal, jak je to super věc, dokud jsem nezjistil, že je to nedomyšlené :-(

JENIIK: a tyhle pomocny struktury jsou pro ORM nejakej problem? to zadani se zakazkama jsem asi uplne nepochopil, ale pocitam, ze ke kazdy zakazce chces mit nejaky soucty (soucet odprac jednotek), prumery, odhady atd.. jestli jsem to dobre pochopil, tak ty mas nejakou pomocnou tabulku, kde udrzujes tyhle soucty atd - je to tak? proc by potom v pripade ORM nemohlo bejt neco jako trida StatistikaZakazky, ktera by pracovala nad nejakou takovou podobnou tabulkou a starala se o tyhle veci?

ale pocitam, ze jsem asi spis neco zasadniho ze zadani spatne pochopil :)

BUTHRAKAUR: mne desi ty veci jako je lazy loading nebo jak se tomu rika a caching a objektova identita. obcas mi napisou kamaradi kteri maji nekde hibernate a dost knouraj. pro mne to bylo docela slozite, nechapu trebas proc bych mel anotovat nejaky property na entitach a urcovat relace na objektovym modelu kdyz to de fakto nedava smysl. ale z druhe strany trebas skladat dotazy z retezcu pro JDBC, klidne i ve Springu je dost oskliva vec :( proto jsem zacal s tim iBatisem.

BUTHRAKAUR: aleale, jako o reportingu moc nevím, živil jsem se tím naplno jen asi rok, ale OLAP není řešení přeci. Existuje spousta důvodů proč musíš někdy použít online data a tam se pak bez redundance a různých statistických sběrů dat v momentě updatu neobejdeš. Jak to pak naládovat do objektů... Nevim. Obecně si myslím, že lidi OLAP dost přeceňujou...

Vem si jako příklad ten můj výpis zakázek, každá má součet odpracovaných jednotek na akcích, datum poslední vydané fa, přijaté fa, objemy obojí fakturace, odhadovanou ziskovost... Tyhle data bys v čistém modelu získával z cca 10 - 15 objektů. A ani čistě relační řešení ti nepomůže, protože výkonově nebude stačit, takže potřebuješ prostě pomocné struktury, kde máš tyhle data pořád velmi rychle k dispozici. Tohle ti obecný framework nezajistí, nehledě na to, že ty data nepoužíváš jen na jednom místě atd atp. Když do toho vleze ještě institut "podzakázky" a shlukování těchhle podzakázek, tak už se z toho zjančíš úplně.

A to je prosím stupidní výpis zakázek, jednoduché zadání, nic složitého.

Možná existuje řešení, které to umí nějak elegantně celé vyřešit, ale mě z toho pořád plyne prostě nějaká hepler class a sql psané pro každou aplikaci a výpis zvlášť, protože prostě jinak to kvůli rychlosti nejde.

JENIIK: zalezi, o jakym typu a rosahlosti aplikace mluvis - ja se pohybuju spis kolem mensich veci.. ale porad si myslim, ze pokud mapper pouzijes spravne a nezabrednes do nejakejch prasaren, tak se vykon nemusi lisit od klasickyho pristupu + navic ziskas vyssi efektivitu pri kodovani.

a s tim reportingem - pokud to s reportingem nekdo mysli vazne, tak stejne skonci u OLAP kostek apod, kam se to stejne pumpuje. a je ve vysledku uplne jedno, jestli se to pumpuje z OR-mapovanejch nebo klasickejch tabulek. bezi mi takhle nad jednou NHibernate aplikaci reporting v Oracle BI a nejak nepozoruju problemy...

TENCOKACISTROMY: každý to použije nějak ohnuté, proto se ptám k čemu to máte. ;-)

JENIIK: nam to slouzi k tomu, ze v aplikacni casti mame vsechno silne typove. tim ziskavame kontrolu nad tim, ze do datetime "sloupecku" necpeme string apod. navic, se silne typovym pristupem ti IDE muze dost ulehcit praci ( vsechny mozny doplnovani, a dohledavani souvislosti, apod ... ).

krome toho nad tim mam udelany SQL-like API pro dotazy na data, ktery je taky silne typovy (+ upraveny tak, aby se z UI lehce prenasely filtracni podminky ).

ale netvrdim, ze to je nejlepsi mozny zpusob, ani ze to je vhodne pouzit ve vsech pripadech.

TENCOKACISTROMY: otázkou pak zůstává k čemu je člověku pak ten samotný datový objekt. Pokud teda neslouží k abstrakci od SQL, což je stejně asi pitomost, protože ty další objekty mají custom SQL v sobě - předpokládám.

JENIIK: tak to mame udelany my. existuje relacni model, ktery je preklopeny do trid v aplikaci. a v aplikaci pak jsou tridy, ktere zarizuji tu praci s datama ( vytvareni novych, kontrola hodnot & souvislosti, automaticky dopocitavani hodnoty & zaznamu, apod... )

objekt reprezentujici datovy zaznam pak ma jen data & par metadat a priznaku typu "titulek atributu (sloupce)", stav zaznamu ( novy, modifikovany, smazany, ... ) a objekty okolo pak zaridi ze se spravne prenese do databaze.

jsem s timhle pristupem docela spokojenej.

TENCOKACISTROMY: no to je to o čem mluvím, jestli není nakonec lepší dívat se na data relačně a udělat si sadu objektů, která ti maximálně usnadní přístup k datům, odstraní redundanci atp...

JENIIK: rozumim, to je beznej postup. ale to se nijak s ORM netluce. proste mas jiny tridy na ty "sesumovany" data nez na ty "zivy".

Ono to je hodne o tom, jak ten objektovej navrh udelas. Muzes mit objekty jako nosice dat a ukladani/validovani/zpracovani muzes mit v jinejch objektech. Nebo naopak ten objekt muze byt autonomni a umet k sobe vsechno mozny. A ani jedna cesta neni uplne spatne ani uplne spravne. Zalezi na konkretni situaci.

TENCOKACISTROMY: nevím, já se dostal do fáze, kdy musím sbírat statictická data bokem do redundantních struktur, protože jinak se k nim v rozumné době nedostanu. A nejde jen o reporting, ale i o přehledové aplikace, které musí zobrazovat nějaká statistická data (klasicky výpis zakázek který zobrazuje souhrny faktur a podobně a který musí jet online).
LITTLELI: viz výše.

Možná blbě popisuju svůj problém s ORM, ale pokud uvažuju čistou aplikaci, pak vytahovat objekty pro jednotlivé fa z předchozího příkladu je samozřejmě hovadina, nechat objekt zakázky tohle zjišťovat pak je už nečisté ale zároveň to není úplně optimalizované. Stejně to nakonec vždycky v těchhle případech končí nějakým klonem SQL který nevrací resultset, ale kolekci objektů a to je podle mě už naprostý nesmysl. Zbytečná vrstva navíc.

Ale nechám se přesvědčit. ;-)

JENIIK: my pouzivame ado.net, coz jsou taky objekty, a s reportingem nemam zadny problem.

LITTLELI: takhle jsem hledal datovou vrstvu, az jsem si ji napsal sam :))

no ono ale tvrdit, ze kdyz neco nebude objekt ale bude to instrinsic ze to bude rychlejsi, to muze platit v syntetickym benchmarku v realite je to skutecne tak, ze dulezity je algoritmus nebo proste spravne rozvrzeni sil v aplikaci a pak u tech virtualnich masin schopnost spravne rozhodnout o tom co inlinovat nebo jestli umi znovupouzivat pametove bloky a kdesi cosi - tedy rekneme schopnost urcite optimalizace ci skalovani, ono zalezi na charakteru aplikace.

JENIIK: nemyslim, ze je to jen tvuj problem. ja jsem co se tyka orm neco jako Sheldon kdyz hleda misto k sezeni, az tak je to spatny :))

TENCOKACISTROMY: tak workflow není ORM, ale skutečně entita, na kterou se objekty vyloženě hodí, že.

Našel jsem ten článek o ebay: http://www.addsimplicity.com/downloads/eBaySDForum2006-11-29.pdf

Je to starší, ale zajímavý.

Sám teď začínám mít radost, že jsem do čistého ORM nezabředl, protože fakt nevím, jak bych řešil reportingy a podobně, pokud bych měl půl aplikace tak a půl onak, tak by mě asi střelilo. Ale to může být jen můj problém ;-)

JENIIK: IMHO se OOP principy neporuci, pokud budu mit v pameti ( nebo nekde jinde ) pole bajtu ( cili NEobjekt ) ktere budou data, jez potrebuju zpracovavat a nekde vedle budu z objektu sestaveny napriklad workflow, ktery s tema datama pracuje. a vysledek muze byt rychly a efektivni.

TENCOKACISTROMY: no o tom právě mluvím, stejně potom dojdeš k tomu, že tu eleganci a čistotu porušíš nějakou prasárnou a hotovo. Univerzální věci fungují dobře, pokud nejsou nějak extra přetěžovány.

IMHO cesta nevede ani tak striktním "objektovým" nebo "relačním" přístupem, ale funkční dekompozicí - myslím, že tu kdysi proběhl článek o tom, jak je organizován vývoj a logika aplikace na které běhá ebay a ta cesta se mi hodně líbila...

JENIIK: ale prd :). i v OOP se delaj vykonny aplikace. jen v nich neni objekt "vsechno".