Susirenki įrašus .. tada renki kitą ... tada pagal poreikį užkrauni.... O jei domain objketas yra POCO tipo? O jeigu pas tave architektūra išscakel'inta ir viskas surišta per WS? Taip ir "klausinėji" pirmyn atgal ORM pagalbą DB, ir siuntinėji objektus. O jeigu ORM duodą gražią sintaksę, kiek developerių realiai pasižiūri kaip ten tos sudėtingesnės užklausos? Jeigu man reikia rezultatų iš vienos lentos, ORM pafetchina dar ir krūva kitų su left outer joinais. Išjungiam lazy loadingą, to nebėra, bet turim kitas problemas :). Arba įrašų šalinimas su ORM. Tarkim 1-n-n ryšys tarp trijų lentelių. FetchAll, cikliuskas ir delete? Bus ragai, tada batchini kas nevisada padeda :) Nesu prieš ORM. Bet tai tikrai nėra panacėja, kuri leidžia atsisakyti SQL'o ir principus reikia žinoti. Blogiausia kai būna sužinomos klaidos sunkiuoju būdu - kai kodas productione, ir neigiamas pasekmės sukelia tiktai staigiai padidėjus vartotojų srautui Biški OT, bet šiuo metu ganėtinai daug buzzo vyksta apie ORM ir šiaip RDBMS naudojimą http://codebetter.com/blogs/gregyoung/archive/2010/02/19/using-an-orm-is-like-kissing-your-sister-part-2.aspx, http://blog.wekeroad.com/2010/02/05/reporting-in-nosql "Arvydas" <neturiu@meilo.com> parašė naujienų news:hlm1hg$946$1@trimpas.omnitel.net... > Galiu kalbėti tik apie NHibernate, kas susiję su ORM skirtu .NET, nes jį > teko kol kas tik realiai čiupinėti tai platformai. Nereiktų pamiršti, kad > vienas iš straipsnių yra 4 metų senumo, kitas straipsnis ne visai > teisingai naudojasi ORM ir, beje, ten nėra pateikiamas Cartesian product > kaip šalutinis efektas. > > Imant pateiktą pavyzdį su komentarais ir tinklaraščio įrašais, įprastai > dirbant su ORM, pirma susirenki visus įrašus ir tada jiems pagal poreikį > įkrauni komentarus naudodamasis atskirom užklausom. Tai už tave padaro > ORM. Be vidinio kešavimo ORM yra ne toks efektyvus kai kiekvienam > puslapiui užkrauti tenka paleisti n+1 kiekį užklausų, bet su kešavimu > vieną kartą užkrovęs visus įrašus, gali juos laikyti atmintyje ir tik > siųsti pakeitimus į duomenų bazę. ORM yra tik įrankis, kurio pagalba kartu > su duomenų ir UI kešavimu galima daug lengviau ir aiškiau programuoti. > > Naudojantis freimworkais visada bus šalutinių efektų, bet kol kas man jie > problemų nesukėlė, o tik padėjo greičiau ir lengviau sukurti produktą. Nuo > kreivų rankų niekas neapsaugos nesvarbu ar naudosi ORM, stored procedures > ar INSERT/UPDATE/DELETE SQL užklausas, klausimas tik kiek tau kodo eilučių > teks prirašyti, kad užbaigtum užduotį laiku. > > Arvydas > www.arvydas.net > > On 18/02/2010 16:45, meska wrote: >> http://ayende.com/Blog/archive/2010/02/04/what-happens-behind-the-scenes-nhibernate-linq-to-sql-entity.aspx >> >> http://ayende.com/Blog/archive/2006/05/02/CombatingTheSelectN1ProblemInNHibernate.aspx >> >> >> :) >> >> "Arvydas" <neturiu@meilo.com> parašė naujienų >> news:hljnfp$pfh$1@trimpas.omnitel.net... >>> Tai niekas ir nesako, kad ORM tinka absoliučiai visom situacijom, bet >>> 99% atvejų jis smarkiai palengvina duomenų saugojimą, validavimą ir >>> kitą CRUD briedą. Kiekvienas padorus ORM turi galimybes gauti duomenis >>> pagal savo sulipdytą SQL užklausą. >>> >>> Gal aš čia mažai patyręs, bet man kažkaip atrodo, kad imti duomenis iš >>> DB naudojantis Cartesian product yra labai neefektyvu, kai yra visam >>> tam sukurti JOIN'ai ir subselectai. Turiu čia priešistoriniam projekte >>> prie kurio dirbu keletą ataskaitų generuojamų naudojantis Cartesian >>> product, tai velnias žino iš viso kam panaudota: nei normaliai >>> atsižvelgiama į DB struktūrą, nei po to lengva maintaininti. >>> >>> Arvydas >>> www.arvydas.net >>> >>> On 18/02/2010 11:57, meska wrote: >>>> "Arvydas" <neturiu@meilo.com> parašė naujienų >>>> news:hlj5a0$s72$1@trimpas.omnitel.net... >>>>> o geriau pasidomėti kas yra ORM ir su kuo jis valgomas. Tada nebeteks >>>>> prasmės kokioj RDBMS duomenys bus saugomi. >>>> >>>> O tada ateis dėdė Cartesian product kartu su n+1 ir pistels per >>>> performance'a :) >>