LINQ to SQL: Beteljesül az álom?

Többen kérdezték meg tőlem, hogy a LINQ to SQL valóban megoldja-e a tipikus adatkezelési problémákat, érdemes-e használni, hogyan fog hatni az alkalmazásokra és azok fejlesztésére? A kérdésre a pontos válasz, hogy a jóég tudja, de azért néhány szempontot érdemes megnézni:

 

1. Unified Storage

A Microsoft ősidők óta próbálja megoldani az egységes tároló rendszer problémáját. Tudjuk, hogy nagyon sokféle adatot akarunk kezelni, ráadásul nagyon eltérőek a tipikus adatkezelési műveletek is az egyes esetekben. Minden ilyen esetre született több-kevésbé optimalizált adattár és elérési API:

  • fájlrendszer
  • registry
  • relációs adatok
  • címtár
  • dokumentumok stb.

Nyilvánvalóan felmerül az igény az egységes tároló rendszer, a unified storage megvalósítására. Ezt az álmot már nagyon sok projekt kergette és még sokáig nem fog megvalósulni. Csak a publikussá vált projektek és kódnevek listája:

  • "Cairo": az objektum orientált operációs rendszer, kb. 1994. Lényegében semmi sem lett belőle.
  • "Hailstorm" avagy .NET My Services: a személyes adatok központosított tárháza a SOAP és a WS-* jegyében 2001-ből. Ezt ugyan kifütyülték a privacyra érzékeny kritikusok és versenytársak, de lássuk be, a Windows Live Services lényegében ennek utózengése.
  • "WinFS" avagy Windows Future Storage: előbb a relációs fájlrendszer, majd a mindent tudó, operációs rendszerbe épített relációs adatbázis álma 2003-ból, megcélozva a közvetkező Windows verziót, az akkor még Windows Longhornnak nevezett, ma Windows Vistaként ismert….izét. A WinFS blog utolsó bejegyzése épp egy éves és akárhogy is cifrázza, lényegében arról szól, hogy a WinFS-ből sem lesz semmi. Matt Warren elég tömören fogalmazza meg a projekt hangulatát:

"We on the outside used to refer to WinFS as the black hole, forever growing, sucking up all available resources, letting nothing escape and in the end producing nothing except possibly a gateway to an alternate reality. Many of our friends and co-workers had already been sucked in, and the weekly reports and horror stories were not for the weak-of-heart. […] There were not too many in the developer division that believed in the mission of WinFS."

  • "ObjectSpaces": ez inkább ORM technológiának készült előbb a .NET 1.1-hoz, majd később a 2.0-hoz. Ennek sorsáról Luca Bolognese blogbejegyzését érdemes elolvasni, beszippantotta a WinFS, ami zsákuktcának bizonyult.

Ezek tehát mind álmok, vagy ahogy a Microsoftnál szeretik mondani: víziók (lásd TechEd megnyitó előadásának bevezetőt itt smile_teeth).

Illik-e ebbe a sorba a LINQ to SQL? Szerintem nem, sőt a LINQ is kilóg belőle. Most éppen nem cél, hogy egyetlen tároló rendszerünk legyen, inkább az a cél, hogy LINQ providerek segítségével az egyes adatbázis motorokat egységesen tudjuk programozni. Ezen a területen úgy látszik jó irányba haladunk.

 

2. ORM

Nyilvánvalóan objektumokkal "szeretünk" dolgozni, sokkal barátságosabbak, mint a rekordok, mezők, attribútumok, kulcsok, relációk. Az ObjectSpaces is ORM technológiának indult, helyét valóban átveszi a LINQ to SQL. Igen, erre remekül alkalmas, valóban minimális kódolással tudunk relációs adatokat objektumokká alakítani és fordítva. Akinek azonban eddig már szüksége volt ORM-re, az vagy írt magának, vagy használt egy létező technológiát, például NHibernate-et és nem valószínű, hogy hajlandóak lesznek váltani egy új technológia kedvéért.

 

3. Produktivitás

Gyorsabban tudunk dolgozni LINQ-kel, mint a korábbi technológiákkal? Nem vagyok benne biztos. A lambda kifejezések világa először nagyon szokatlannak tűnik, eltart egy darabig, amíg megszokjuk, ráadásul nincs dizájnerünk, csak IntelliSense. Miután belerázódtunk, valóban kevesebb kódot kell írnunk, már ha eddig írtunk egyáltalán adatelérési kódot. Sokan már eddig is generálták a DAL kódot, vagy használták a VS beépített varázslóit. Mivel ezek a trükkök közvetlenül ADO.NET kódot eredményeztek a LINQ-féle indirekció nélkül, ezért már csak teljesítmény okokból sem érdemes nekik váltani. Sokaknak vannak már kész osztályaik az ADO.NET kód egyszerűsítésére, nekik valószínűleg hatékonyabb a már megismert eszközeiket használni, mint megtanulni a LINQ-et.

 

4. Architektúra

Ez szerintem a kulcskérdés: hogyan fog változni az alkalmazások felépítése a LINQ megjelenésével?

  • Az egyszerű alkalmazásoké sehogy, továbbra is szétszórva lesz benne az adatelérési kód DAL nélkül, csak éppen nem ADO.NET, hanem LINQ szintaktikával – feltéve, hogy azzal produktívabbak vagyunk.
  • A többrétegű alkalmazásoké sem fog változni, hiszen nem változhat, épp ez a lényeg. Adott egy szigorú felépítés, azt kell követni, a technológia mindegy. Itt tehát marad a DAL, a produktivitás persze dönthet arról, hogy milyen technológiával készül el (lásd az előző bekezdést).
  • Strukturálatlan alkalmazások: már most is van néhány olyan alkalmazás, amelynek igazán nincs felépítése, a VS varázslói közvetlenül odakötözték az adatbázis táblákat a felhasználói felület vezérlőkhöz. Mivel a varázslók remekül beváltak ezekben az esetekben, itt nincs helye a LINQ-nek.

Ha egy már létező alkalmazásban szükség van ORM-re, akkor ott arra már valószínűleg született egyfajta megoldás, amit nagy valószínűséggel nem fognak átírni. A LINQ to SQL tehát akkor fog ORM célokra elterjedni, ha zöld mezős alkalmazásokban van lehetőség használni és meg is éri használni (megint csak produktivitás).

 

Összegezve: a LINQ to SQL nem egy tökéletes megoldás a lassan évtizedek óta létező problémákra, hanem inkább csak egy megoldási alternatíva. Eggyel több lehetőséget kell figyelembe vennünk, amikor implementációs technológiát választunk. Mivel a Microsoft elég sokat tett fel a .NET 3.5 platformra, mindenképpen érdemes jobban megismerkedni vele.

 

Technorati tags: , , ,
Reklámok

Vélemény, hozzászólás?

Adatok megadása vagy bejelentkezés valamelyik ikonnal:

WordPress.com Logo

Hozzászólhat a WordPress.com felhasználói fiók használatával. Kilépés / Módosítás )

Twitter kép

Hozzászólhat a Twitter felhasználói fiók használatával. Kilépés / Módosítás )

Facebook kép

Hozzászólhat a Facebook felhasználói fiók használatával. Kilépés / Módosítás )

Google+ kép

Hozzászólhat a Google+ felhasználói fiók használatával. Kilépés / Módosítás )

Kapcsolódás: %s