> ORMerna lovade databasoberoende och att man skulle slippa skriva SQL
> och slippa mappa sina objektstrukturer.

> * Numera har vi insett att de inte ger databasoberoende (queries som
> fungerar olika). Låtsas du att stöder alla databaser måste du också
> testa det. Då börjar det kosta.
> * SQL är inte svårt, det är däremot kraftfullt och tydligt. Ofta blir
> det merjobb för att få sin ORM att ställa rätt SQL-fråga. Resultatet
> blir att jag måste hantera både SQL och en ORM.
> * Objektstrukturer: Det är ju trots allt bara data och operationer.
> Måste det vara ett objekt? Hämta datan, visa den, manipulera den nära
> databasen istället. Ofta har vi rader av data i databasen, vi mappar
> dem till objekt, och visar rader av data på en webbsida. - Vad tillför
> objektmappningen till lösningen?
> * Om du skall testa dina queries inuti din IDE, vad är enklast att
> sätta upp och testa: Mappade hibernate-objekt eller ett JDBC-anrop?

> Henrik Johansson

> On 1 Dec, 10:37, Peter Lundberg <peter.lundberg...@gmail.com> wrote:
> > +1 för abstraktionsproblemet som John beskrev!

> > Jag har även en komplexitetsvy på det: Även om allt fungerar för CRUD,
> > tycker jag att man skall man beakta hur mycket komplexitet man drar in i
> sin
> > lösning och inte falla för “golden hammer” anti-pattern.

> > Och då menar jag inte bara den komplexitet man skriver själv, orm med
> > annoteringar ser förföriskt enkelt ut, utan mest hur många lager
> teknologi
> > och rader kod och beroenden som man plockar in för att lösa problemet.
> Denna
> > dolda komplexitet är något jag tycker många inte ser eller tar hänsyn
> till –
> > tar man in teknologin skall man underhålla den över tiden och den skall
> > funka. När den inte fungerar måste de som vidareutvecklaresystemet kunna
> > felsöka och förstå den, även om några år. Jfr en klassisk orm strack
> (spring
> > + hibernate + cache + jdbc driver + RDBMS + filsystem) med enkla filer
> > (java.io + filsystem) med någon nosql (driver + enkla operationer +
> > filsystem). Storleken på ens lib katalog i drift är ett grovt men
> intressant
> > mått.

> > Mvh
> > Peter

> > On 11-12-01 10:15 , "Olle Kullberg" <olle.kullb...@gmail.com> wrote:

> > > För CRUD-operationer funkar allt: ORM, Relationsmodell,
> Dokumentmodell...

> > > @Joakim Om man för över data kontinuerligt från en dokumentdatabas
> till en
> > > analysdatabas (ES) så får man nästan samma data. Man måste nog räkna
> med att
> > > analysdatabasen ligger några millisekunder efter (vilket kan ge fel).

> > > /olle

> > > 2011/12/1 √iktor Ҡlang <viktor.kl...@gmail.com>

> > >> 2011/12/1 Joakim Ohlrogge <joakim.ohlro...@agical.com>
> > >>> Åh vad bra formulerat!

> > >> Johnny är rätt badass.

> > >>> -----------------------------------------------------
> > >>> Joakim Ohlrogge
> > >>> Agical AB
> > >>> Västerlånggatan 79, 2 tr
> > >>> 111 29 Stockholm, SWEDEN

> > >>> Mobile: +46-708-754004 <tel:%2B46-708-754004>
> > >>> Blog: johlrogge.wordpress.com <http://johlrogge.wordpress.com>
> > >>> Twitter: @johlrogge
> > >>> E-mail: joakim.ohlro...@agical.se

> > >>> 2011/12/1 John Nilsson <j...@milsson.nu>

> > >>>> Oj gammal tråd ! :)

> > >>>> Min erfarenhet är att ORM:er dels abstraherar bort så mycket av den
> > >>>> rationella modellen och den underliggande databasen att du tappar
> det det
> > >>>> mesta den kan erbjuda. Varför backa din modell rationellt om du
> ändå inte
> > >>>> drar nytta av det? Dels så tvingar de in objekt-modellen i ett
> datacentrikt
> > >>>> perspektiv vilket gör att du samtidigt tappar möjligheten och
> nyttan med en
> > >>>> objektorienterad modell.

> > >>>> Resultatet ORM blir därför bara mappning, vilket bara är kostnad.

> > >>>> Eventsourcing och CQRS verkar erbjuda ett alternativ som jag håller
> på att
> > >>>> utvärdera för tillfället. Du får fråga igen om ett år så skall vi
> se om jag
> > >>>> reviderat min ståndpunkt ;)

> > >>>> MVH,
> > >>>> John

> > >>>> Den 1 dec 2011 08:21 skrev "anpeo" <anders.u.pers...@gmail.com>:

> > >>>>> Runt mig tala det mycket om ORM och hur bra det är dock i en C#
> värld,
> > >>>>> skulle vara snällt om du kunde berätta varför du gärna undviker det
> > >>>>> är det en Scala sak eller något rent generelllt. ?
> > >>>>> /A

> --
> Det här meddelandet skickas till dig eftersom du prenumererar på gruppen
> scala-sverige i Google Groups.
> Om du vill göra ett inlägg i den här gruppen skickar du e-post till
> scala-sverige@googlegroups.com.
> Om du vill sluta prenumerera på den här gruppen skickar du e-post till
> scala-sverige+unsubscribe@googlegroups.com.
> För fler alternativ, besök gruppen på
> http://groups.google.com/group/scala-sverige?hl=sv.