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".

BUTHRAKAUR: no já teda nechci zase vypadat jako zpátečník, ale v momentě, kdy tě začne zajímat výkon aplikace, pak na všechny objekty zapomeneš, protože ono se v tom hezky píše a všechno vypadá elegantně, problém je ale v tom, že někdy musí elegance stranou a jde se po výkonu.

Jenže to se někdy těžko vysvětluje i lidem, pro něž je třetí normální forma dogmatem a tak, to si prostě musí každý ozkoušet sám.

TENCOKACISTROMY: hmm.. koukam, ze primo na strankach ceny nemaj - zkusim si schvalne vyplnit Price Inquiry. pokud by byla ta cena takhle nizka, jak rikas, tak to vazne trochu meni situaci :)

jestli si dobre pomatuju, tak cenova politka db4o u komernich projektu je $9 za 1 licenci v provozu ( + mnozstevni slevy ). to je oproti mssql/oracle cenove uplne nekde jinde.

LITTLELI: na to jsem koukal.. s db4o uz jsem kdysi i pokusoval a nenarazil jsem na zadnej zasadni problem, co se tyce funkce - problem je spis s tim presvedcit zakaznika k nakupu neceho jinyho nez oracle/mssql :/

BUTHRAKAUR: jo to me taky sere :( nicmene teda ted nacpali do db4o linq - coz pro tebe jako .netistu musi byt pomerne zajimave.

SHAGA: nj, pro mne je zlo relacni model a ORM je nastroj na zmirneni relacni bolesti :)) a bohuzel investice objektovejch DB nejsou dostatecny, aby se ODBMS nejak vyraznejs prosadily ;(

ORM je zlo. Cokoliv, co se snaží maskovat fakt, že relační a objektový model jsou dvě různé věci, skončí tak, že buď se spousta černé automagie po chvíli zhroutí a začne generovat prapodivné chyby apod., nebo tak, že se přiohýbá db modelování objektovému, což vede k - slušně řečeno - suboptimální výkonnosti. iBatis a spring JDBC abstrakce jsou imho ideální, schovávaj JDBC prudu s checkovanejma výjimkama a resource managementem a přitom nechávají člověku v rukou plnou kontrolu.

no tomu rozumim, jenze ja mam problem v tom, ze neuridim hibernate a tu jeho temnou magii uvnitr - a ze to je temna sila o tom doufam, nikdo nepochybuje :)