Ska databasutvecklaren släppa hörnflaggan?

Vi har haft en hel del intressanta diskussioner på jobbet senaste tiden där allt bottnar kring användandet av nästa generation av ADO.NET (EDM) och även LINQ.

Med dessa båda tekniker så kan man exempelvis enkelt skapa en objektstruktur baserad på en relationsdatabas och få stöd för CRUD-operationerna utan att skriva en enda rad kod.

Sett i perspektiv av produktivitet så är detta enormt, all tid som tidigare lades ner på att skriva lagrade procedurer och dataaccessmetoder är som bortblåst och man kan istället fokusera på att använda informationen i sin applikation.

Ett problem som dock uppstår är att tidigare så kunde man i en projektgrupp ha en distinkt skiljelinje mellan applikationsutvecklare och databasutvecklare i form av lagrade procedurer. På detta vis kunde en databasutvecklare göra vad han ville i en databas så länge som den lagrade procedurens parametrar och resultat aldrig ändrade sig. Denne kunde också genomföra mängder av datavalideringar om så önskades.

Om man nu vill nyttja produktivitetsvinsten som man kan erhålla med exempelvis LINQ så fungerar inte detta längre, dvs. en databasutvecklare kan inte längre ändra ett kolumnnamn utan att det slår på något sätt för applikationsutvecklaren, må så vara att det i vissa fall enbart är att ändra i en konfigurationsfil. Det finns ett beroende som inte tidigare fanns där…

Frågan är därmed om det inte är dags för databasutvecklaren att släppa hörnflaggan och komma in i matchen. Att våga bryta ny mark och kanske ansvara för dataaccesslagret skrivet i exempelvis .NET också? I så fall kan man fortsätta göra de förändringar och valideringar man alltid gjort men hela utvecklingsteamet får en produktivitetshöjning.

OK, nu säger några av er som läst på kring EDM:er och LINQ att man kan ju använda lagrade procedurer ändå och då uppstår inte detta problem. Men då undrar jag, vill man inte nyttja tekniken fullt ut?