Hej
När tycker ni att man ska använda en O/R Mapper? Min känsla är att det är overkill i mindre projekt.
Det finns många utvecklare som kan SQL och stored procedures. Det finns färre som kan en specifik O/R mapper. Enligt min uppfattningn ska man inte anta att det är samma personer som förvaltar/vidareutvecklar ett system som en en gång konstruerade det. Detta gör att det uppstår ett kompetensproblem då man ska utföra underhåll på ett system med en O/R Mapper.
Hur gör ni?
/Patrik

Man skall alltid använda ORM ;)

Skämt å sido, stort / iltet projekt spelar ingen roll. Det handlar om huruvida du modellerar din applikation objekt orienterat eller inte. Gör du det vill du ha en ORM för den underlättar ngt fruktansvärt vid utvecklingen. Gör du inte det så måste du först lära dig OO och sen ORM.

F-ö tycker jag att argumentet "det finns fler som kan x än y" är ett helt galet argument. Om man får produktivtetsvinster, vinster i underhåll eller vinster överlag. Då introducerar man den tekniken och sen får man helt enkelt lära upp de som skall förvalta.

Har skrivit en post om det http://www.lowendahl.net/showShout.aspx?id=225

Jag tror det är lite tvärt om, det är lättare att ta över system som nyttjar ORM än inte. Om ORM delarna nu implementeras på rätt sätt efter en konsist modell. (Dvs inte ligger spritt lite över allt i koden så som vissa än idag råkar programmera med ADO .Net.)

Bara fördelen att slippa förstå vad massa SPs gör och ha koll på vad parametrarna både in och ut håller på med underlättar mkt för många då man kan fokusera mer på sin domän och applikationens funktionalitet istället för att grotta sig i massa SPs... Att bara få bort detta lager underlättar massor... Dessutom minskar risken till businesslogik i ens Sps och på så vis kan man även få bättre enhetstester där man enkelt kan koppla bort sin db för slippa fylla den med massa skräp. Fördelarna är många... Patrik har bla många goda poster på sin blogg rörande både ORM och SPs så läs dem gärna... Som Patrik även pekade lite på så kommer användandet av ORM även göra att många som idag inte förstår OO eller OOP få större förståelse för det då man mer eller mindre automatiskt kodar därefter utan att kanske direkt veta om det…

>>Man skall alltid använda ORM ;)

Nej :)

Men, en kombination av object mappning med sp's är bra, databasen är trots allt mycket snabbare att söka än någon linq, mapper "what ever" kommer att bli.

Och det man ska veta är att det i färdiga orm(ar) som tex nhibernate och llblgen ofta uppstår performance problem när systemet växer.

Håller med Patrik, använd alltid en ORM :)

Om man av olika skäl väljer att inte använda en ORM så använd åtminstone repository pattern :) , det borde vara mycket lätt att lära ut då det är ett relativt simpelt pattern.

>>Om man av olika skäl väljer att inte använda en ORM så använd åtminstone repository pattern :) , det borde vara mycket lätt att lära ut då det är ett relativt simpelt pattern.

precis repository är inte så tokigt , men som jag sagt tidigare man ska känna till fallgroparna som finns kring vissa färdiga generella ORMappers , talas rätt lite om de problem som kan uppstå om de används på fel sätt.

>Och det man ska veta är att det i färdiga orm(ar) som tex nhibernate och llblgen ofta uppstår >performance problem när systemet växer.

detta är ju nått man även skall ta hänsyn till när det växer... oftast är det vi själva som orsakar problemen o inte mappers...

>>oftast är det vi själva som orsakar problemen o inte mappers...

exakt och det är där den första frågeställningen i den här tråden kommer in , den eviga frågan om sql programerarna klarar av att förstå oo och ddd eller ska man helt enkelt låta dem hållas

jag har sett exempel på där en utvecklare i gui't skapade dataset med tillhörande datatables och datarows utifrån en fin Ilist<t> fylld med domän entiteter han fått från ett repository. och sedan använt datasettet för att mappa mot gui controllers. så problemet med okunskap/ointresse är tyvär rätt vanligt.

Och det grundar sig tyvär i att ms fortfarande visar exempel på datasetnivå och inline sql i aspx filer.

ja du... det är mkt man sett och alltid kommer se :-)

Dataset o jag är inte polare så där förstår jag frustrationen... Men folk måste vilja lära sig, idén med teamwork och gruppproejtk är just att vara enade och göra på rätt sätt... Om man är osäker skall man ju "väga" fråga någon som man vet kan. Vilket i ofs inte är så vanligt altid att de gör... Ståltheten är svår att svälja ibland och många tror det är en svaghet att fråga om hjälp när det faktiskt är tvärt om...

Men det är som i alla brancsher... folk gör fel, folk gör rätt, man behöver vägledas, vissa måste göra samma misstag om o om igen tills de får en spark i baken, andra behöver mer tid på sig att ta till sig det nya och obekväma m.m... Det är tyvärr så vi lever och kommer göra...

De som inte vill läras av andras misstag får väl tyvärr göra dem själva synd att det är så vanligt bara att det är så...

Tyvär så är det ju så de flesta har svårt att erkänna för sig själva att de måste fråga. Det blir ju så otroligt mycket mer effektivt utvecklingsarbete när deltagare i teamet frågar varandra istället för att sitta och grotta med små problem som man stirrat sig blind på och inte google klara att svara på.

Där kommer scrums's dagligamöten rätt bra tillhands , fast även i dem kan det vara svårt att få igång en sådan dialog där någon måste erkänna att han eller hon inte klarar av en viss uppgift.

Plain Vanilla SQL/SqlDataReader är ca 8 gånger snabbare än de hetaste ORM-lösningarna på markanden i dag, enligt en magisteruppsats om .NET Entity Framework publicerad i våras:
http://gupea.ub.gu.se/dspace/handle/2077/10462

Berättar ni det för era kunder när ni tillverkar era cleana domändrivna modeller? Eller, ni kanske bara bloggar om de här sakerna.. ;)

Den <b>pragamatiska utvecklaren</b> tar hänsyn till denna faktor också.

Ett annat problem med ORM är att kunskapen om relationsDB och SQL glöms bort.
Det kan aldrig vara bra.

Kolla på PDF:en, räkna ut vad som händer om ni ska ha många användare i era system.

Köpa ny server? :)

>>Plain Vanilla SQL/SqlDataReader är ca 8 gånger snabbare än de hetaste ORM-lösningarna på >>markanden i dag, enligt en magisteruppsats om .NET Entity Framework publicerad i våras:
>>http://gupea.ub.gu.se/dspace/handle/2077/10462

allright vetenskapligt bevis på att jag har rätt mao :)

Helt ärlig blir jag less på den här diskussionen.

1) SP's är /inte/ snabbare än en parametriserad t-sql fråga. Det har de inte varit sen SQL Server 7. Alla sådana påståenden är ren lögn. /Om/ det finns prestanda skillnader så beror det på helt andra faktorer än hurvida det är en dynamiskt genererad t-sql fråga eller om /samma/ fråga finns inne i en SP.

2) Assembler är snabbare än C#, så vi borde skriva alla applikationer i assembler istället. Hela diskussionen om prestanda är så fruktansvärt tröttsam. Ja SQL Data Reader är mycket snabbare eftersom den inte behöver overheaden med att flytta data till objekt. Men poängen med ORM är inte att vara det snabbaste alternativet, det har det aldrig varit. Poängen med ORM är att tillåta utvecklarna att jobba objektorienterat och modellera applikationer med det verktyg som bäst löser uppgiften. År av erfarenhet har format den lösningen och det är därför vi har så många objektorienterade språk. Så vad OO ger mig är möjligheten att jobba mycket effektivare och skapa lösningar som är billigare att underhålla, det gör jag genom en trade-off vad gäller prestanda. Precis samma typ av trade-off som jag gör när jag väljer att använda .NET istället för assembler.

Hela "x är snabbare än y" debatten är så fruktansvärt löjlig. Jag vill inte ha en F1 bil om allt jag skall göra är att köra till jobbet fram och tillbaka.

3) LINQ och andra mappers låter SQL server sköta sökningar. Så argumentet faller på punkt 1.

>> "Ett annat problem med ORM är att kunskapen om relationsDB och SQL glöms bort.
Det kan aldrig vara bra. "

På 80 talet sa man att t-sql språken fick utvecklare att glömma bort hur man accessar databasfilerna med vanlig C.


ORM, LINQ och dylikt är en abstraktion över ett koncept. Tanken med abstraktioner är att alltid förenkla för den som använder koncepten och låta utvecklare fokusera på sin specifika applikation istället för infrastruktur och annat tjafs.

"Och det man ska veta är att det i färdiga orm(ar) som tex nhibernate och llblgen ofta uppstår performance problem när systemet växer. "

Intressant påstående, har du något som du kan backa upp det med? Jag upplever inte att NHibernate ger några prestanda problem när systemet växer. Tvärtom skalar oftast de systemen bättre än ett system som överanvänder SProcar.

>>Intressant påstående, har du något som du kan backa upp det med? Jag upplever inte att >>NHibernate ger några prestanda problem när systemet växer. Tvärtom skalar oftast de systemen ><bättre än ett system som överanvänder SProcar.

men läs uppsatsen som postades lite tidigare då.

som jag och Johan diskuterade så är det ju så att om man använder dem fel , tex läser upp allt då man instansierar ett objekt , så kan det sänk ett system. det handlar om okunskap i det fallet och en okunskap som grundar sig i att de flesta inte är intresserade av vad som händer under huven. Och att det blir enkelt att få tillgång till allt på ett fint oo sätt.

Jag gillar oo och ddd , och använder mig av det men jag är skeptisk till dessa ramverk som inte är optimala i de specifika fall de används.

Vill inte vara den, men ibland undrar man om folk är födda i farstun ;-) hehe... nä skämt o sido...
Håller med Patrik punkt o pricka... Så egentligen behöver jag inte säga så mkt mer men kan inte låta bli. :-) Sådan är jag...
Det finns typ en siffra på att utvecklare lägger ca 80% av sin tid på att optimera kod helt i onödan. Så jag blir faktiskt rätt mörkrädd när jag hör dessa argument som BARA baseras på OLD School faktorer där man inte själv som utvecklare tar reda på egen fakta och eller ens inser att det som sades igår gäller inte idag.

Ex ORM nyttjar bla DataReaders... En ORM hjälper även till att MAPPA sina objekt ett arbete som du ev ändå måste utföra som bara tar tid... Kollar man på den processen så är prestandan nästan exakt detsamma... någon millisecund hit eller dit men man spar tid vilket spar pengar... En millisecund går att optimera på andra ställen som to m blir mer kostnadseffektivt...

>Berättar ni det för era kunder när ni tillverkar era cleana domändrivna modeller? Eller, ni kanske >bara bloggar om de här sakerna.. ;)

HAHA. denna var låg... Nästan som att säga Min lärare sa en gång att trådning är för töntar... HAHA... Sorry du bjöd på den kunde inte låta bli... i 9 fall av 10 bryr sig inte kunden om tekniken de vill ha funktionen med bra kvalité, till bra pris och även kunna få billiga och enkla och smidiga uppdateringar. Kan säga att då har du en nöjd kund...

Det är exakt samma låga nivå inom digitalkamera världen, ju mer megapixel man har ju bättre måste ju bilderna vara? man kommer ALLTID leta efter nått fjantigt att klandra på och just prestanda är det absolut faktiskt fjantigaste argument som idag kan tas upp i många fall i alla fall i ca 80% av fallen. Man bryr sig om nanosecunder, millisecunder, ticks m.m för att försöka motvisa alla bra idéer.

För 10 årsedan sa man att OOP var kass för det måste ta massa prestanda att hoppa mellan massa metoder...
Man sa att vattenfallsprocessen var den bästa...
Man klagade på flattextfiler som datakälla sen kom XML...
Man klagade på det som var som webbservicec (mins inte namnet nu) för det var slöare än marshalling sen kom webservcies

Ja det är mkt man klagat på...

Men allt slutar alltid med samma vishet... OJ vi gjorde för bra system o det kosta för mkt... Vi optimera för 10000 användare men bara 10 skulle använda systemet och vi fick betala trippelt så mkt... O ändå sitter samma stollar och gör samma fel om och om igen... Tragiskt...

>Den <b>pragamatiska utvecklaren</b> tar hänsyn till denna faktor också.
Ja den tar till faktorn att prestanda inte är logisk utan ser till praktiken... Att säga att SP är snabbare för att man en gång sa det är inte pragmatiskt... Sjuka är att man än idag lägger massa businesslogik i sina SPs vilket istället belastar dbn på fel sätt... Bra prestanda det där…

Nepp... nu skall jag ta mig en kopp kaffe... känner att jag behöver det... ;-) Ibland undrar man… vad får vi allt från. ;-)

Andreas...

Du är inte skeptiskt till ramverken :-) Du är skeptisk till folket som använder dem på fel sätt ;-)
Men håller med dig om en sak. ORM funkar i ca 90-95% av allt man gör i ett system, sen finns undantagen dem kommer vi aldrig ifrån oavsett teknik eller ramverk... Inte ens .net klarar allt idag vilket även i vissa projekt gör att vi kör undandat med annan teknologi... Så är det ju alltid o kommer alltid att vara...

Det är den ottroligt stora bristen på okunskap vi har inom programmerare som är boven, de borde ta sig i nacken och inse att kunskap är viktigt att vara programmerare skall inte vara lättare än vara en kirurg... men idag är det så lätt att bara kalla sig programmerare plocka ut fetelönen och sen kan man knapp svara på vad man gör.. :-)

>> men läs uppsatsen som postades lite tidigare då.
Jag har läst den och några till som gjorts av elever och även om de kan påvisa att prestandan är sämre med en ORM, så klart för det är en abstraktion, så har de inte på något sätt påvisat att skalbarheten skulle ta stryk. Och nej skalbarhet och prestanda är inte samma sak. Skalbarhet kan påverka prestanda negativt medans bättre prestanda inte behöver påverka skalbarheten positivt.

När det gäller hurvida system klarar att växa så är prestandan underordnad, det är saker som låsningar, state och hanteringen av fasta resurser som spelar roll. Där hamnar också stored procedures, med tunga SP's i databasen så kommer du snabbare till punkten där systemet inte längre kan skala än utan dem. Det är en av anledningarna till att tex Gregory Hophe, arkitekt på Google, bannlyst sproccar för adsense projekten.

Sen är det igen så att ORM är en abstraktion som skall underlätta utvecklingen av OO system som sparar data i en relationsdatabas. Abstraktioner kostar i ena änden för att ge vinster i den andra. I just ORM fallet så handlar det om att minska tiden jag som utvecklare behöver lägga på infrastruktur.

"men läs uppsatsen som postades lite tidigare då."

Nu orkar jag inte läsa igenom hela uppsatsen, men en sak är helt klar och det är att bara för att man får ut maximal prestanda så betyder det ju inte att man skalar speciellt bra. Utan oftas är det så att ju bättre prestanda, ju sämre möjlighet att skala ut och tvärtom.

I övrigt så kan jag bara hålla med Patrik i hans resonemang. För 95% av alla system som man utvecklar så bör man funderar på att låta prestandan ge vika för underhåll och utveckling av systemet. Visst det tar längre tid att använda sig av ORM mappers eftersom det finns en del overhead i dessa. Men samtidigt så har du avsevärt förkortat din utvecklingstid jämfört med att själv mappa upp data till olika objekt. Om man inte väljer att jobba enligt OO så finns det ju inte så mycket nytta med en ORM men igengäld så (anser iallafall jag) har man ett system som är svårare att underhålla och vidareutveckla.

Så i slutändan så kommer det i det flesta fallen vara en bättre lösning att köpa in en större server och hosta din lösning på, och utveckla den enligt OO/DDD och använda sig av ORM. Än att fokusera på prestandan, dock inte sagt att man skall nochalera prestandaspekterna helt, men i detta fall så väger övriga fördelar över...

- M

Jag vill heller inte negligera prestanda som aspekt i ett system. Däremot är jag av den övertygelsen att jag börjar oroa mig för den när jag har ett dokumenterat problem som uppenbart inte uppfyller kraven från verksamheten. Det finns viktigare saker att oroa sig för, om att affärslogiken är korrekt tex.

Magnus... Håller med dig för en gång skulle ;-) hehe... Kors i taket... haha...

Det roliga med artikeln är just att man inte tagit hänsyn till bla utv-tid etc... Utan gnäller på fjuttiga 300 Millisecunder...
Skulle vart mkt intressntare o se vad allt de olika scenarierna tog i utv-tid och då i ett sötree scenario än bara tre-fyra klasser.

Staplarna skulle se mkt intressanta ut då. Skulle nog nästan kunna säga att DataReader staplen skulle bevisa tiden det skulle ta att utveckla med ORM vs de andra stamplarna om man inte gjorde det. När detta väl var klart och någon funktion ev skulle ha ett prestandaproblem så är det enkelt att byta ut mot Reader i de fallen för öka prestandan. Ev kanske stapeln skulle öka lite till då i tid men aldrig ens vara i närheten av att uppnå de andra staplarna.

Förvaltningen sen skulle visa sjuka staplar som jag inte ens vill gå in på rörande endast datareader faller i tid vs ORM projektet...

Men det blir lätt så när skolor gör blinda research de tar inte med helheten rörande projekt utan stirrar blint på en liten detalj... Som Patrik sa de kunde lika gärna skrivit det i assembler o fått ännu mindre stapel än DataReader faller i prestanda... :-)

Vad ni tjatar om SP, debatten handlar ju inte alls om det.
(Lite straw man varning på era argument nu!)

Ang att spara utvecklingstid, inte nödvändigtvis sant med ORM i många fall.
Möjligen om man inte fattar SQL då, men det är ju mer ett kompetensproblem än ett arkitekturproblem i så fall.

Exempel.
Så här tar man bort en order med ORM:en Entity Framework.

Enligt en annan skön bloggare, Anders J:

http://andersjonsson.blogspot.com/2007/12/ta-bort-en-order-via-entity-framework.html

;)

using (NorthwindEntities db = new NorthwindEntities())  
{  
Orders o = db.Orders.Include("Order_Details").Where(oo => oo.OrderID == orderId).ToList()[0];  
  
foreach (Order_Details od in o.Order_Details.ToList())  
{  
o.Order_Details.Remove(od); // detta "frikopplar" od  
db.DeleteObject(od);  
}  
  
db.DeleteObject(o);  
  
db.SaveChanges();  
}

Spara tid? Var då?

Så här brukar jag göra, utan någon ORM.
Mindre kod. Bättre prestanda. Lika skalbart.
Enklare att underhålla eftersom det är mindre kod som kan skita sig.

'Imports Microsoft.Practices.EnterpriseLibrary.Data
Dim db As Database = DatabaseFactory.CreateDatabase("OrderDB")
Return db.ExecuteNonQuery("OrderDeleteById", OrderID)
' Order-tabellen har en cascading delete som tar bort relaterade OrderDetails
' (det är inte affärslogik för det har inte med affärer att göra. Det är databasintegritet, inget annat!)

Svårare behöver det inte vara!
Jag kan nu koncentrera mig på funktionalitet, användbarhet, stämma av krav med mina glada användare, AJAXbonusar, osv..

:-D

Glöm nu att det är en SP som anropas. Det ger bara snyggare kod i detta fall.
(Jag säger inte att det är angeläget ur prestandasynpunkt att göra alla 'DeleteOne' med lagrade procedurer, men det skadar ju knappast att slippa inline SQL..)

ps. Alla UPD/INS/DEL1 SProcar är autogenererade så .. vem sparade mest tid? ds.

:-)

Det är alltid så kul att se hur folk försöker bevisa fel saker till fel personer... Så kommer det alltid att vara... Det finns 101 begginers forum för sånt... Det är ju inte så att de som idag sitter med ORM aldrig någonsin använt andra ramverk eller tekniker genom åren... Det finns ett skäl till varför man går över till nya tekniker och inte är det för att de nya är heta och inne utan för att man faktiskt been there done that...

Det kommer alltid finnas motståndare till allt som är nytt för folk har så förbaskat svårt för att lära sig nytt eller ändra sina gammal vanor... Utvecklingen går frammåt en utvecklare som skall gnälla och argumentera om att old school saker är bra bör inte va utvecklare... utan invecklare... eller nått...

Så jag är glad att Patrik Johansson ställde frågan...


Ola:
Varför jämför du bara med Entity Framework? Någon som sagt till dig att den är bäst o optimalast?

Exemplet du jämför med är inte helt optimalt i jämförelsen... Sen är det vart koden ligger som är en viktig del i det hela oxå. VAD den gör mer för dig... Ex i ditt fall; har du UoW (Unit of Work) stödet? Eller måste du hantera det själv varje gång? Har du Identiyt mapping i det du gör för att ex få prestandaökning m.m???

Har du lazy load hantering? m,m.

Det är ju inte den ensklida raden i programmering som är det viktiga utan vad helheten generellt gör för dig...

Läsbarhet, enkelheten att göra förändingar, tydligheten att hitta fel snabbt, andra features ORM gör för dig som du istället måste implementera för hand etc...

Det går lika fort att tanka disel som 95 oktan. men oj du kommer faktiskt flera mil längre med disel ;-)

Ola,

För det första EF är en V1. NHibernate tex klarar av cascading deletes. För det andra, du glömde att skicka med koden till sproccen som du också måste underhålla. Varför skulle du f-ö vilja att ett verktyg autogenrerar mer kod som du måste underhålla? Varför inte bara låta verktyget kapsla in koden? Det är för mig obegripligt.

Samma kod i NH:

session.Delete(obj);

Vilket i sin tur kan ta hand om cascading deletes, ordningen så att FK's tas bort osv.

Vad gäller sp's så är det ett svar på en tråd längre upp där man, felaktigt, hävdar att sp's skulle på ngt sätt vara "snabbare".

Sen undrar jag om du ärligt kan säga att du arbetat med ORM, med tanke på dina svar här så känns det som att du baserar dina åsikter på att läsa bloggar och labba runt lite. Då är det ganska klart att det verkar bökigt med ORM, det är ju inte alls samma teknik som du jobbat flera år med och då blir det ju så klart lite mer jobb tills du är lika kompetent med ORM som med din gamla teknik. Jag kan ärligt säga att jag gjort som du beskriver och jag är väldigt nöjd med den produktivitet jag nu får när jag jobbar med ORM jämfört med hur det var på den "gamla goda tiden".

Det finns många beginnerforum för SQL också :)
ORM är inte nytt. Inte OOP heller. Inte för mig iaf. :)
Och det stämmer inte att jag är emot ORM. Varför skulle jag orkar vara "emot" ett för användaren ganska trivialt API som anropar SQL? (Och varför tror vissa ORMister att de är raketforskare för att de har lagt ner SQL?) Jag är lite skeptisk bara till den nya trenden att vissa tror att man kan glömma SQL pga att det nu finns några nifty devtools som skapar SQL automagiskt (med varierande resultat). På samma sätt som en del trodde de kunde programmera schyssta databasapplikationer med Drag'n'Drop i MS Access för några år sen.

>Och varför tror vissa ORMister att de är raketforskare för att de har lagt ner SQL?)

Vilka påstår detta?

Asså bara för man använder ORM betyder inte att man lägger ner SQL. Men i 90% av fallen behövs ju inte TSQL alls och i många projekt inte alls. Varför ödsla tid på kunskaper man inte behöver? varför använda det bara för att det finns?

Vi kan lika gärna koda i ADA eller Haskell oxå... varför inte lära sig messaging i windows oxå?
varför inte lära sig hur man pixlar en icon? så alla kan pixla iconer? varför inte kräva att alla kan XPath för XML, XML är lika mkt datakälla som en Db... m.m.

<b>Vi kan lika gärna koda i ADA eller Haskell</b>
Äntligen ett vettigt förslag!
;-)

Jag har läst lite bloggar forum osv och håller med om att det faktum att man använder en bra ORM kan ge prestandavinster.

Argumentet är att man oftast får ner komplexiteten med en ORM och att man då oftast har mindre logiska fel som drabbar prestandan negativt.

Annars så gillar jag ORM, tråkigt att sitta med sqlsatser och mappning det är en maskins uppgift jag vill hålla på med mer intressantare saker. Sedan finns det något ORM:en gör dålig så kan man ju alltid fixa det när problemet uppstår i NHibernate t.ex. kan du helt ta över hur saker mappas osv om det behövs.

Ola, jag försöker inte överbevisa dig om något, var och en får välja att utveckla på det sätt som man vill, jag och johan är inte överens alla saker, inte låter jag det påverka mig, lyckas han inte övertyga mig om det han tror på är bättre än det som jag tror på så kör jag på, på mitt sätt.

När jag hänvisade till att man sparade utvecklingstid så utgick jag ifrån att man använder sig av OO alltså att du jobbar med olika objekt i din kod och inte bara records av data. Om du inte använder dig av OO när du utvecklar så finns det heller ingen vinst med en ORM eftersom hela iden är ju att man mappar från databas till objekt.
Om man dock väljer att jobba med OO och inte väljer en ORM så är det ju så mycket mer än bara ta bort ett object ifrån databasen, det är ju hela hanteringen att få data från databasen in till objektet och sedan tillbaka från objekten till databasen som du måste hantera själv. Och det är där som jag ser att man vinner utvecklingstid, speciellt när det är många objekt som skall fyllas med data och speciellt om dessa objekt frekvent kommer att ändras, vilket sker om man utvecklar efter Agile. Här ger ORM massor med tidsvinster.

Ju mer jag jobbar med DDD destu mer överbevisad blir jag av jag har valt rätt väg att vandra (jag är långt ifrån någon expert inom DDD), men överblicken man får och isoleringen av vad varje objekt ansvara för är extremt viktig när det gäller att underhålla och vidareutveckla koden. Och det säger jag med 10 års erfarenhet som utvecklare. Jag säger inte att du måste tycka eller känna likadant, bara att jag gör det, och precis som ovanstående personer har jag den långa vägen vandrat från att binda dataset direkt till kontroller i code-behinden till att fylla fylla egna objekt med data till att använda ORM och fokusera mer på att lösa problemen istället för att stirra mig blind på vilken teknik som används....

- M

>> varför inte kräva att alla kan XPath för XML

Johan där sa du nått , j-vlar va snabbt xpath är :P

Den här disukssionen är ju som att snacka religion , ungefär som javatomtarna (ja de flesta har ju skägg) vs microsoftfalangen för ca 10år sedan. lite synd att den håller på att splittra .Net i olika läger
kanske Patrik en dag blir en alt.net vp istället för mvp :)

Jag tror(vet) att en väl skriven egendefinierad och anpassad för sitt ändamål "mapper" med sql / sp's i botten och ett datareader lager är rätt väg, man får sin domänmodell som man vill ha den. det blir skalbart (ok Patrik kanske man kan skippa sp'arna för den saken som tydligen googel gjort de tillför inte mycket när det gäller CRUD) och det blir snabbt. Det krävs inte särskilt mycket mer tid att utveckla och underhålla ett sådant system , Ok det kanske tar lite längre tid att skapa grunden än några "click" i någon färdig orm-wizzard eller vad det nu må vara. Men du får total kontroll över det du gjort ingen magi kommer ställa till något underhuven i det läget då lasten på systemet ökar. Du slipper också ta all overhead som finns i färdiga produkter för att klara av alla tänkbara situationer som ditt system aldrig kommer att komma i närheten av.

Vad gäller de lagrade procedurerna så kommer de väl tillpass när det gäller att ta fram tex rapporter ur databasen, för vi är väll överns om att vi fortfarande lagrar data i en relations databaser.
Detta eftersom de flesta rapport verktyg på marknaden har dåligt stöd för simpla poco's så måste man i många fall ändå ha sp's som ska underhållas.

Rapporter är en helt annan femma, rapporter funkar så där i en OO värld till att börja med. För rapporter är det bättre att använda verktyg som är direkt byggda för det. Rena BI verktyg som Crystal Reports, performance point server och MDX tex. Inte gärna sprocs.

Att bygga en /egen/ mapper är väl gott och väl, men du måste väga tiden för utveckling och underhåll av den mot produktiviteten du får av en generisk mapper (jag vill inte själv gärna bygga inverse management, UoW, concurrency handling, identity map, load spans i onödan). I många fall är det inte värt den lilla "prestanda" vinst du kan får, speciellt inte om du med en generisk mapper ändå oftast uppnår de krav på prestanda som verksamheten kan ha.

Vidare med sprocs, jag säger inte att det bara är CRUD operationer som man skall strunta i sprocs, de är det lilla problemet. Det stora problemet är folk som lägger bussiness logik i sproc, den skall absolut inte vara där. Dels för begränsningen av skalbarheten och dels för att T-SQL är ett riktigt ruttet språk för att uttrycka komplex affärslogik i.

Jag ser inte heller den här diskussionen som en "religions"-debatt. Det handlar om att vara pragmatisk och lägga sin tid på det man tycker är viktigt. Jag lägger inte gärna min tid på att bygga ett DAL och en ORM om någon annan redan gjort det, då kan jag istället lägga mer tid på att lösa verksamhetens problem.

Jag tror heller inte att den kommer splittra communityn, snarare ena den. Utvecklingen går hela tiden mot generiska abstraktioner för att snabbare kunna skapa affärsvärde. .NET var en sådan abstraktion, T-SQL var en sådan abstraktion, NHibernate och Entity Framework är en annan sådan abstraktion. Varje sådan abstraktion har slagit igenom historiskt, trots att det "kostat" prestanda därför att produktiviteten blir så mycket högre, samma sak kommer att ske med ORM nu när Microsoft äntligen gett sig in på marknaden. På java sidan har det redan slagit igenom och där finns det en standard specad för hur ORM skall funka.

Hej,

Jag tycker att ni glömmer bort en sak (som jag alltid har sagt). I projekt med komplexa databaser, och där teamet är stort, kommer man oftast att ha en DBA. Han/hon vet bäst hur man optimerar SQL (ja, mycket bättre än vad någon OR mapper klarar av). Då ger SP's en abstraktion mellan DB'n och applikationen, som kan behövas. Många java/.net utvecklare klarar inte av att göra en komplex databasdesign, och inte heller att skriva SQL för att använda den på ett optimalt sätt.

Man döljer helt enkelt databasens interna struktur för utvecklarna, precis som de döljer affärslogiken för folket som gör ren presentation.

Nu snackar jag alltså om stora system med komplexa databaser där datamängden förväntas bli stor. I mindre projekt/system håller jag med om att OR mappers är grymt trevliga.

/K

Jag glömmer absolut inte DBA'er, DBA'er har ett väldigt viktigt arbete i att se till så att datat är framtidssäkrat och lagrat på bästa sätt. De står helt enkelt för specialkunskapen runt databasmotorn och det är så klart inte försumbart. Däremot ifrågasätter jag att deras perspektiv på lösningen alltid skall lägga begränsningar på vad övriga team kan göra. Allas perspektiv är lika viktiga och det gäller att hitta en medelväg för varje lösning. Dessutom ifrågasätter jag tre saker med den "sanning" som de oftast står för :

1) Måste alla frågor alltid vara 100% optimerade? Jag anser inte det och även i diskussion med optimerings-gurn Kalen Delaney förra veckan på Sql Summit så var hon inne på samma linje. Man optimerar de 10% som verkligen är ett problem och inte alla 100%. Alla bra ORM tillåter att man ställer egna queries i de fall som optimeringen verkligen behövs. Dvs övrig ORM funktionalitet kan man fortfarande, i stort, få hjälp med.

2) Vad gäller strukturen på databasen så är inte SProcs det verktyg man skall användar. Om jag som dba vill gömma strukturen och skapa en abstraktion vad gäller strukturen så skall jag använda vyer, dels för att det går att ställa vanliga frågor mot en vy och dels för att ur ett optimeringsperspektiv så kan man skapa index på en vy det kan man inte göra på en stored procedure.

3) Liknande argumentet att dba'er bättre kan optimera t-sql än vad en ORM kan göra har använts förut. Man sa samma sak när de första query optimizers såg sitt ljus tex, då ansågs det att query optimizern aldrig kan bli lika "optimerad" som direkt access till binärfilerna med ren C kod. I dag är det få som inte använder T-SQL och query optimizern. Man litar i stort på att den oftast gör ett bra jobb. När det gäller query generatorerna så är storyn ganska lika, de första som användes för 10 år sedan var ganska crappy men efter att de använts i 1000-tals system så börjar de bli bättre och bättre tweakade och den som är gjord för Entity Framework är dessutom skriven av Data Programability teamet på Microsoft tillsammans med några av utveckleckarna från Query Optimizer teamet. För mig innebär det att jag kan lita på att frågan som genereras är den bästa /generella/ frågan för just det scenariot. Som sagt innan, behöver jag speciella frågor för mitt scenario så är det inget som är inkompatibelt med ORM, men jag vill hävda att det är 10% av mina queries, inte 90.

I slutändan så handlar det om att leverera affärsnytta med så hög kvalité som möjligt. Det kommer att handla om trade-offs, tex extrem prestanda mot produktivitet (samma trade-off som nämnts förut assembly vs .net tex). Desto mindre projektet behöver fokusera på infrastruktur och annan repetitiv kod desto mer tid finns över för att verkligen optimera för affärsperspektivet.

Jag tror att bristen på erfarenhet kring användadet av ORM och den typ av design och arkitektur som krävs gör att folk argumenterar emot ORM.

Btw, många ORM kan arbeta mot Store Procedures om vi så vill det.

Många utvecklare designar sin applikation efter databasen och låter den driva designen, de lägger först fokus på hur datan ska lagras. Men det är oftast helt ointresant hur data lagras, det viktiga är att skapa en domän modell som kunden och utvecklaren förstår och som löser kundens problem, sedan när modellen är klar, först då fokucera på hur och vart datan ska lagras, det kan resultera i att en databas kanske inte är bästa alternativet.

När Microsfot pratade om deras visioner kring data access, då nämde de ADO.Net Entity Framework. De sa att med hjälp av Entity Framework så kan nu utvecklare skapa sin domän modell, sedan kan DBar mappa databasen mot utvecklarnas modell. Utvecklarna kan jobba med sin modell och DBar med databasen och optimera den. Att utvecklaren ska behöva anpassa sig efter en DBa är helt befängt! En utvecklare vet hur man bygger applikationer, en DBa vet hur man skapar en databas, låt då dessa få göra det dom är bäst på. I den perfekta Object Oritenterade världen om vi tänker som ett objekt istället för en dator, så skulle en Object Orienterad databas vara det perfekta alternativet för oss utvecklare.. tyvärr har dom sina brister och är ännu inte en mogen platform även om dom har funnits ett tag.

Mvh Fredrik Normén
MVP - MEET - ASPInsider

http://weblogs.asp.net/fredriknormen

1) Nej alla frågor behöver inte vara optimerade, inte när man arbetar med små mängder data. När man däremot har miljontals rader så kan det skilja väldigt mycket.

2) Vyer är bra i vissa fall men sämre i andra. Det har visserligen blivit bättre med ny syntax i SQL Server 2005/2008, men inte perfekt. Jag använder vyer eller SP's, det som passar bäst i varje specifikt fall.

3) I flera system med stor datamängd har jag/vi fått använda hints för att optimera där query optimizern fallerar. Det verkar inte vara så ovanligt vad det gäller stora datamängder, framför allt i de fall man har table valued functions inblandade. Sen kanske du argumenterar att man inte ska använda sådana... :)

/K

1) Det gäller även stora mängder data. Query optimzern gör ett ganska grundläggande bra jobb.

2) En vy handlar om strukturell integritet, stored procedures om logik i databasen. Använd rätt verktyg till rätt uppgift. Som jag sa innan, om performance verkligen är ett problem så har du enorma fördelar med vyer eftersom de kan indexerar separat från tabellerna.

3) Vid edge cases, som TVF är, så förstår i dagsläget inte optimizern. Det är en teknisk begränsning som beror mer på hur TVF fungerar än hur optimizern funkar.

Jag säger inte att det inte finns tillfällen där man måste använda lock/index hints, vad jag menar är att oavsett datamängd så för de allra flesta frågor så kan man tweaka index bra nog för att generiska frågor skall ge den prestanda som är "good-enough". Utan att vara tvungen att skriva om frågorna.

De är också så att för tex NHibernate så kan du konfigurera en hel del vad gäller hur frågan skall genereras. Typ, skall det användas outer join, sub select, inner join etc. Det som saknas är att kunna specificera hints i mappningen, sen kommer väldigt många scenarion att vara täckta.