Nem sok infó, de nekem nagyon ObjectSpaces OR Mapperes szagú az ügy, gondolom hangsúlyozottan a LINQ közvetlen támogatására.
This entry was posted
on Tuesday, September 26th, 2006 at 11:52 am and is filed under .NET, Adatbázisok, C#, Szakmai élet.
You can follow any responses to this entry through the RSS 2.0 feed.
You can leave a response, or trackback from your own site.
September 26th, 2006 at 7:58 pm
Szerintem nagyon durván jó lett, főleg a c# 3.0-val. A DLinq tényleg OR mapper-szerű, viszont ami nagyon tetszik, az a LINQ SQL szintaxisa a collectionökre providermodellestül-mindenestül, meg hogy ez az egész végre párhuzamosításra is jó módszer lesz a PLINQ-kel.
var q =
from c in Customers
where c.City == “London”
select c;
és akkor mondjuk mindez egyszerre több szálon, adott esetben hashtáblákon keresztül automatikusan optimalizálva fut le. Szép is lenne végre. Amikor már nem azt mondjuk meg, hogy hogyan akarjuk elérni az eredményt, hanem azzal tudunk foglalkozni, hogy mit szeretnénk elérni, és az optimalizációt rábízzuk a motorra. Még a párhuzamosított, multi core környezetben egyre fontosabbá váló “query plant” is cacheli a motor, tisztára mint az SQL.
És akkor még gondoljuk ehhez hozzá, mi történik majd, ha az Orcas idején kijön a Software Transactional Memory a Vistában most érkező, Kernel szinten megvalósított KernelTransaction kezeléshez csapódva, ami már NTFS és Registry terén képes a tranzakciók kezelésére. Lehet, hogy végre lehet majd a kliensoldalon is hatékony, multicore-ra is skálázódó, többszálas kódot írni? Nemár :) El se hiszem.
Node az is ide tartozik (számomra, bár az ADO.NET-től már messze járok), hogy végre a lockolást is egyszerűsítik, és nem kell szupermennek lenni több párhuzamos szál értelmes és hibamentes kezeléséhez.