• úvod
  • témata
  • události
  • tržiště
  • diskuze
  • nástěnka
  • přihlásit
    registrace
    ztracené heslo?
    BUTHRAKAURObject Relational Mapping :: rady, tipy, triky
    JENIIK
    JENIIK --- ---
    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. ;-)
    TENCOKACISTROMY
    TENCOKACISTROMY --- ---
    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 :))
    LITTLELI
    LITTLELI --- ---
    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 :))
    JENIIK
    JENIIK --- ---
    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 ;-)
    TENCOKACISTROMY
    TENCOKACISTROMY --- ---
    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.
    JENIIK
    JENIIK --- ---
    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...
    TENCOKACISTROMY
    TENCOKACISTROMY --- ---
    JENIIK: ale prd :). i v OOP se delaj vykonny aplikace. jen v nich neni objekt "vsechno".
    JENIIK
    JENIIK --- ---
    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.
    BUTHRAKAUR
    BUTHRAKAUR --- ---
    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 :)
    TENCOKACISTROMY
    TENCOKACISTROMY --- ---
    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.
    BUTHRAKAUR
    BUTHRAKAUR --- ---
    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 :/
    LITTLELI
    LITTLELI --- ---
    BUTHRAKAUR: jo to me taky sere :( nicmene teda ted nacpali do db4o linq - coz pro tebe jako .netistu musi byt pomerne zajimave.
    BUTHRAKAUR
    BUTHRAKAUR --- ---
    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 ;(
    SHAGA
    SHAGA --- ---
    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.
    LITTLELI
    LITTLELI --- ---
    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 :)
    BUTHRAKAUR
    BUTHRAKAUR --- ---
    LITTLELI: hmm.. to mi teda prijde takovy podivne magicky a nepruhledny :) teda aspon to generovani SQL ciste podle signatury metody - nejak jsou mi blizsi ty atributy/anotace, jako to ma treba Castle.ActiveRecord... skoro mi teda ale prijde, ze se ten iBatis s (N)Hibernate temahle poslednima/planovanejma zmenama zacinaji celkem hodne priblizovat.
    mne to primitivni CRUD SQL nebavi, takze zustanu u NH, ale ceka mne ted prepsani jedny aplikace nad takovou celkem brutalni oldskull DB strukturou, tak uvidim, jestli se nakonec nebudu muset k iBatis taky uchylit...
    LITTLELI
    LITTLELI --- ---
    aaaah, ad dynamic sql. jo to je ono. je to jenom takovej templating s parametry.
    LITTLELI
    LITTLELI --- ---
    BUTHRAKAUR: melo by to byt tohle. kdy to bude nevim, to tam nikde nepisou :) nicmene pro to pak nepotrebujes explicitni sql. jinak v soucasnosti ano, a to mi zase tolik nevadi.. stejne nekde potrebuju testovat model, pripravit fixtures, takze mam vsecko podchycene.
    BUTHRAKAUR
    BUTHRAKAUR --- ---
    LITTLELI: ted se asi trochu ztracim :) dynamic sql myslis tohle? to je akorat trochu rozsirena syntaxe tech vygenerovanejch/psanejch dotazu, jestli to dobre chapu = porad musis tomu frameworku dodat klasicky SQL dotazy i pro primitivne mapovany operace.

    a pod tim "implicitni resp. konvenci rizene dotazy podle nazvu dao metod" si muzu predstavit co presne? nejaky rozsireny mapovani pomoci atributu?
    LITTLELI
    LITTLELI --- ---
    BUTHRAKAUR: aha a neresi to ta moznost kterou nazyvaji dynamic sql? ja tu prave mam ted aplikaci, ktera je vyvijena z datoveho modelu a nejsem si uplne jistej, jestil by mi (n)hibernate byl po ruce. pokud vim do v3 planujou nejaky zmeny jako implicitni resp. konvenci rizene dotazy podle nazvu dao metod.
    Kliknutím sem můžete změnit nastavení reklam