O/R-mappning och krav på verktyg

Personligen är jag inget stort fan av O/R-mappers och kanske mest på grund av att jag inte haft tid att sätta mig in i hur de som finns idag verkligen fungerar och nyttan med dessa. Däremot är jag ett stort fan av kodgenerering i alla dess former och har tidigare varit med i ett par projekt med lyckat resultat där vi till stor del automatgenererade dataaccesslagret. Det är så skönt att kunna fokusera på affärslogik istället för lagrade proceduranrop.

Ser man till O/R-mappers så tar man ju det här med automatisk kodgenerering ett steg längre, och för att kunna dra riktigt stor nytta av detta så finns det en del saker man bör tänka på vid val av produkt/ramverk för just O/R-mappning.

Jag läste i morse just en intressant artikel kring detta som du hittar på länken nedan. Håller du med författaren? Är dina erfarenheter likvärdiga?

Top 10 Must-Have Features in O/R Mapping Tools

Comments

• Anonymous
  October 10, 2005
  Tycker han mer beskriver ett kodgenereringsverktyg än en runtime O/R-mapper. För mig är O/R runtime.
  
  Min erfarenhet är att runtime O/R-mappers (genom att använda reflection eller IDispatch) är att de ofta är för långsamma då det är en serverlösning med många anrop. Funkar nog till många lösningar, men det är för långsamt att använda vid t.ex. batchorienterade serverlösningar.
  
  Kan däremot tala varmt om kodgenereringsverktyget Codesmith (finns även som freeware) där man själv får skriva templates och beskriva hur koden skall skapas. Du kan då själv välja vilket "ramverk/metodik" man vill implementera. Iom stödet för partial classes i VS2005 så är det ännu enklare att använda dessa verktyg (codesmitch stödjer iofs redan nu att ersätta all kod inom en namngiven region, typ #region Auto Generated code). Skulle gissa att 80% av alla lagrade procedurer med tillhörande datalager kan genereras, och då får man sin egen kodstandard på både lagrade procedurer och datalager samt prestanda.