Linq - fordele og ulemper

For:

LINQ samler 3 forskellige teknologier under en fælles syntaks:

LINQ to objects (arrays, eller rettere sagt IEnnumrable, af objekter), LINQ to SQL og LINQ to XML.

Det bliver derfor lettere at arbejde med disse på en ensartet måde.

Udviklingstiden bliver hurtigere på de områder som dækkes af LINQ. Det er derimod lidt svært at sige noget om indlæringstiden – hvor hurtigt kommer man i gang.

Koden bliver mere kompakt; Noget SQL-kode som før tog mange linjer at skrive kan skrives på ganske få i LINQ to SQL. Kompakthed er selvfølgelig ikke et mål i sig selv, men med f.eks. LINQ to SQL bliver hensigten af en given stump kode mere klar end når den er delt ud over mange forskellige typer af SqlXXX kommandoer.

LINQ introducere typestærkhed i sammenhænge hvor vi ikke har haft dette før. F.eks. har der ofte været brug for type casting i SQL sammenhænge.


Imod:

(Well, man kan jo bare lade være med at bruge det)

LINQ er integreret i Visual Studio vha. en del automatisk kode generering som foregår uset i baggrunden. Folk som har brug for at arbejde med LINQ fra f.eks. kommandoprompten eller i en alternativ editor som f.eks. SharpDevelop er ikke så ”heldige”.

Omvendt kan man hævde at dette i sig selv er en ulempe for VS folkene. Jo mere automatisk kode editoren laver for dig, des mere er du på herrens mark når du har brug for at ændre på denne – det er ikke din kode og du kender den ikke lige så godt som hvid du selv havde skrevet den.

Ved at simplificere tingene for dig, er der nogle teknologier som programmørerne nu vil komme meget mindre i kontakt med: Vi ser allerede f.eks. fænomenet med alle de ASP.Net- og WinForms-kontroller som acceptere en datasource. Da denne kan laves via drag'n'drop programmering i VS er der mange opstartende programmører, som ikke aner hvordan man arbejder med en database på det helt fundamentale niveau. Denne tendens vil blive forstærket med LINQ og vil nu komme til at omfatte viden som f.eks. XPath søgninger.

Man skal til at lære en ny syntaks. Foruden LINQ så er det lambda expressions, extension methods og anonyme typer som et minimum. Der er selvfølgelig god ide i at lære disse at kende under alle omstændigheder, men man kan ikke fravælge dem hvis man ønsker at dyrke LINQ.

Til trods for at LINQ samler tre teknologier under en fælles syntaks så må man ikke forlades til at tro at de opføre sig 100 % ens under motorhjelmen; Man kan derfor komme til at sidde og kæmpe med en fejl som optræder i en LINQ-teknologi, men ikke i en anden.

Der har længe været et vist misforhold mellem OOP modellen med dens klasser/objekter og disses indbyrdes forhold, samt den relationelle model dvs. databasemodellen med dens tabeller/data og disses relationer. Hvordan gemmer man på meste logisk måde et objekt-træ i en database?

Dette har mundet ud i forskelllige persisterings frameworke som f.eks. NHibernate:

http://en.wikipedia.org/wiki/NHibernate

LINQ er muligvis et alternativ til disse, og en fordel ved LINQ kunne derfor være at den forhåbentlig formindsker gabet mellem OOP modellen og RD modellen.

Hvad med noget respons?

??

Beklager, jeg skulle lige flytte :)

Mange tak, det var en stor, stor hjælp :)

Smid et svar, tak !

Svar :^)

Naar man taler om fordelene ved LINQ for SQL, saa skal man efter min mening skelne
mellem to ting selvom MS har bundlet dem:
1)  O/R mapper funktionaliteten
2)  LINQ syntaxen

#1 er saerdeles nyttig, men er ikke nyt - man har i flere aar kunnet bruge LLBLGen eller NHibernate eller et af de mange andre O/R mapper produkter til .NET.

#2 er helt nyt men til gengaeld er jeg lidt skeptisk overfor nyttevaerdien.