[InstalledProductRegistration(false, "#110", "#112", "1.0", IconResourceID = 400)]

public selaed class MyPackage: Package { ... }

public static class StringResolver<TPackage>

  where TPackage: Package

{

  public static string Resolve(string toResolve);

  public static bool ExistsInResourcesClass(string key);

  public static string ResolveInResourcesClass(string key);

  public static bool ExistsInPackageResources(string key);

  public static string ResolveInPackageResources(string key);

  public static Type GetResourcesClassType();

}

public static class StringResolver<TPackage>

  where TPackage: Package

{

  private static readonly Dictionary<Assembly, Type> _ResourceTypes =

      new Dictionary<Assembly, Type>();

  // ...

  public static Type GetResourcesClassType()

  {

    Assembly callingAsm = typeof(TPackage).Assembly;

    // --- Check the cache for Resources type and return if found.

    Type resourceType;

    if (_ResourceTypes.TryGetValue(callingAsm, out resourceType))

    {

      return resourceType;

    }

    // --- Search for the Resources type. If found add it to the cache.

    foreach (Type type in callingAsm.GetTypes())

    {

      if (type.GetCustomAttributes(typeof(CompilerGeneratedAttribute),

        false).Length > 0 && !type.IsVisible && type.Name == "Resources")

      {

        _ResourceTypes.Add(callingAsm, type);

        return type;

      }

    }

    return null;

  }

  // ...

}

// ...

public static bool ExistsInResourcesClass(string key)

{

  Type resourceType = GetResourcesClassType();

  if (resourceType == null) return false;

  PropertyInfo propInfo = resourceType.GetProperty(key, BindingFlags.Static |

    BindingFlags.NonPublic);

  return propInfo != null;

}

// ...

public static string ResolveInResourcesClass(string key)

{

  Type resourceType = GetResourcesClassType();

  if (resourceType == null) return Resources.ResourceNotFound;

  PropertyInfo propInfo =

    resourceType.GetProperty(key, BindingFlags.Static | BindingFlags.NonPublic);

  if (propInfo == null) return Resources.ResourceNotFound;

  return propInfo.GetValue(null, null).ToString();

}

// ...

// ...

public static bool ExistsInPackageResources(string key)

{

  Guid packageGuid = GetPackageGuid();

  string resourceString;

  IVsResourceManager resourceManager =

    (IVsResourceManager)Package.GetGlobalService(typeof(SVsResourceManager));

  if (resourceManager == null) return false;

  int result = resourceManager.LoadResourceString(ref packageGuid, -1, key,

    out resourceString);

  return result == VSConstants.S_OK;

}

// ...

public static string ResolveInPackageResources(string key)

{

  Guid packageGuid = GetPackageGuid();

  string resourceString;

  IVsResourceManager resourceManager =

    (IVsResourceManager) Package.GetGlobalService(typeof (SVsResourceManager));

  if (resourceManager == null) return Resources.PackageNotFound;

  int result = resourceManager.LoadResourceString(ref packageGuid, -1, key,

    out resourceString);

  if (result != VSConstants.S_OK) return Resources.PackageNotFound;

  return resourceString;

}

// ...

private static Guid GetPackageGuid()

{

  return typeof(TPackage).GUID;

}

// ...

public static string Resolve(string toResolve)

{

  if (string.IsNullOrEmpty(toResolve) || toResolve.Length < 2) return toResolve;

  if (toResolve.StartsWith("#"))

  {

    toResolve = toResolve.Substring(1);

    return toResolve.StartsWith("#")

      ? toResolve : ResolveInPackageResources(toResolve.Trim());

  }

  else if (toResolve.StartsWith("$"))

  {

    toResolve = toResolve.Substring(1);

    return toResolve.StartsWith("$")

      ? toResolve : ResolveInResourcesClass(toResolve.Trim());

  }

  return toResolve;

}

public selaed class MyPackage: Package

{

  // ...

  protected override void Initialize()

  {

    // ...

    string myWindowCaption = StringResolver<MyPackage>.Resolve("$WindowTitle");

    // ...

  }

  // ...

}

A LINQ-kel való ismerkedés során elindítottam egy „kísérleti” nyílt forráskódú projektet a CodePlex-en. A projekt egyelőre még nem publikus, július közepére tervezem, hogy megnyitom. Várom azok visszajelzését, jelentkezését, akik résztvennének ebben a kísérletben. A projekt eredményeinek egy kis részét megpróbálom bemutatni a június 25-ei Platform Innovációs Napokon, mielőtt megkezdeném rendes nyári szabadságomat, amelyről július 9-én térek vissza.

Két dolog kapcsán tekintem kísérletinek a projektet:

Ø  Szeretném kideríteni a LINQ használhatóságát (erősségeit, gyengeségeit), miközben meglehetősen mélyen megismerkedem annak implementációs részleteivel.

Ø  Kiváncsi vagyok, hogy tud-e itt nálunk egy teljesen közösség nyílt forráskódú projekt működni.

A LINQ over C# projekt lényege olyan LINQ kiterjesztés (provider) elkészítése, amely egy C# projekt állományait (a benne lévő projekt fájlt és kódállományokat) olvasva közvetlenül a projekt, illetve a kód elemeit le tudja kérdezni. (A háttérben egy C# szintaktikai és szemantikai elemző fog állni, amely nagyjából minden tud, amit egy C# fordítóprogram, de MSIL kódot nem bocsát ki.)

A projekt még alpha állapotban van, de már teljes egészében működik a szintaktikai elemzés (C# 2.0). Még rengeteget kell rajta fejleszteni és hangolni, de az eddigi eredmények biztatóak.

A projekt során nyílt forráskódú C# projektek forráskódján tesztelem a rendszert (pl. NUnit, CSLA).

Az alábbiakban bemutatok néhány ilyen lekérdezést, amelyeket az Orcas Beta 1-el hajtottam végre egy virtuális gépen. A lekérdezéshez a CSLA projekt forráskódját használtam fel.

A C# projekt szintaktikai elemzése

Az alábbi programrészlet a megadott könyvtárban lévő C# projekt összes forrásfájljának szintaktikai elemzését végzi el. A projekt későbbi változataiban ennek explicit leírására már nem lesz szükség:

A CSLA projekt 85 forrásfájlja esetében a teljes szintaktikai elemzés kb. 280 ms-ot vett igénybe.

Egy C# projektben található fájlok lekérdezése

A lekérdezés 2 ms alatt adta vissza az érintett 85 fájl nevét.

A névterek lekérdezése

Az alábbi lekérdezés visszaadja a projektben található összes névteret és azt, hogy melyik hány részletben került definiálásra (minden fájlban található definíció egy önálló részlet):

A lekérdezés eredménye:

Az összes típus lekérdezése

Az alábbi lekérdezés visszaadja az összes típust, amelyet a projekt definiál:

A generikus típusok összegyűjtése

Az előző lekérdezés egy kis módosítással a generikus típusokat adja vissza:

Eredmény:

A legtöbb metódust tartalmazó típusok

Egy összetettebb lekérdezéssel megvizsgálhatjuk, hogy mely típusok tartalmazzák a legtöbb metódust:

Eredmények (részlet):

A DataPortal osztály legtöbb utasítást tartalmazó metódusai

Az előző lekérdezések még olyanok voltak, hogy azokat akár a Reflection típusok segítségével egy lefordított C# assemblyből is le tudtuk kérdezni (forráskódból azért nem!). Ezt a lekérdezést már csak a forráskód elemzésével tudjuk megtenni:

Eredmények:

A „result” lokális változó előfordulási helyei

A mintapéldákat egy olyan lekérdezéssel zárom, amely kiírja, hogy mely típusok melyik metódusai definiálnak „result” nevű lokális változókat, illetve a kapcsolódó forrásfájl melyik sorában teszik ezt:

A lekérdezés eredménye:

Már közel egy éve a legtöbb Microsoft fejlesztői konferencia nem engedheti meg magának, hogy legalább egyszer meg ne említse a „LINQ”-et, mint a C# 3.0-ás változatának alapvető újítását. Csak nemrégiben kezdett a köztudatban is letisztulni, hogy mindaz, amit a .NET 3.5-höz és az „Orcas”-hoz kapcsolódóan nyelvi újításként emlegetett a Microsoft, valójában nem egyszerűen néhány új C# nyelvi elemet jelent.  A .NET keretrendszer egy olyan új technológiával gazdagodott, amely alapvető információkezelési feladataink során az SQL nyelvhez hasonló módon deklaratívvá teszi adatok összegyűjtését, lekérdezését.

Bár a LINQ a Language Integrated Query (hevenyészett fordításban a „nyelvbe ágyazott lekérdezések”) megnevezésből alkotott mozaikszó, a technológia lényege számos ötletes —nyugodtan használhatom a „zseniális” jelzőt — elgondoláson és a fordítóprogrammal való szoros integráción alapszik.

Ebben a cikksorozatban körbejárom a LINQ alapjait, bemutatom a technológia legfontosabb jellemzőit. Néhány ponton benézünk majd a „kulisszák mögé” is, hogy jobban megismerhessük mi is van a háttérben.

Lépések a LINQ felé

A LINQ-et a bevezetőben úgy említettem, mint a .NET 3.5 egy új technológiája az adatlekérdezési, információfeldolgozási feladatok megvalósításának támogatására. Hogyan ad ez a technológia értéket a fejlesztők mindennapi tevékenységéhez? Ezt a kérdést talán úgy vizsgálhatjuk meg, ha némi betekintést nyerünk a technológia működési alapjainak néhány részletébe. Ebben a fejezetben lépésről lépésre bemutatom egy viszonylag egyszerű adatfeldolgozási folyamat során azt, hogy a jelenleg használt megoldási minták irányából hogyan juthatunk el a LINQ teljes szolgáltatáshalmazának kiaknázásáig.

Legyen a feladatunk egy olyan jelentés előálltása, amely ügyfelek és a hozzájuk tartozó rendelésállomány alapján területenként előállítja az értékesítési statisztikát, vagyis azt, hogy mely területen (településen) mennyi volt a teljes és rendelésenkénti átlagos értékesítés.

Adatfeldolgozás „hagyományos” módon

Alkalmazásunkban az adatréteget a Customer és Order típusok képviselik, amelyek az ügyfelek és a hozzájuk tartozó rendelések adatait személtetik:

Szintén entitásként jelenik meg a ReportItem típus, amely az értékesítési statisztika egy bejegyzését tartalmazza:

Az alkalmazás üzleti funkciói (jelenleg ez a riport elkészítése) A BusinessLogic típusban kapnak helyet.

Az Application típus az alkalmazásunk megjelenítési rétegét, illetve a vezérléséhez szükséges logikát tartalmazza:

Most, hogy alkalmazásunk rétegei adottak, építsük fel azt az üzleti logikát, amely az értékesítési statisztikát előállítja. Ha ezt a jelentést egy adatbázisból kellene előállítanunk, ahol a Customer és Order entitásoknak megfelelő táblák megtalálhatók, valahogy így írnánk le az ehhez szükséges SQL lekérdezést:

Ugyanezt a logikát imperatív módon is leírhatjuk, rengeteg megvalósítás lehetséges. Én az alábbi megoldást választottam:

Hogyan is viszonyul az imperatív kóddal leírt megoldásunk a fejezetrész elején leírt SQL-szerű megoldáshoz? Nem vitatható, hogy az SQL-szerű leírás rövidebb és érthetőbb is. Ugyanakkor a .NET jelenlegi eszközeivel (a .NET alapobjektum-könyvtár segítségével) nekünk csak egy a fent vázolthoz hasonló megoldás marad. A „kézi” megoldás kialakítása során több olyan részletre is figyelnem kellett, amelyeket egyébként egy adatbáziskezelő eszköz az SQL lekérdezések segítségével saját hatáskörében megold:

Ø  Indexet készítettem a Customer példányokhoz (customerIndex), hogy az egyes ügyfelek az Id tulajdonságukon keresztül egyszerűen elérhetők legyenek. Ha ezt nem tettem volna, egy ciklus segítségével kellene megtalálnom egy adott azonosító alapján a hozzá tartozó ügyfélobjektumot.

Ø  Önálló lépésben létrehoztam egy munkatáblát  (work), amely a jelentés elemeinek aggregációját segíti.

Ø  A rendelésállomány elemeit egyenként végigjárva előállítottam a kívánt eredményhalmazt.

Ø  Az eredményhalmaz egy közbenső, az aggregáláshoz használt formában állt elő, azt olyan formára (List<ReportItem>) kellett hozni, amely megfelel az üzleti funkció elvárt kimenetének.

A működés ellenőrzéséhez az z Application típus InitData metódusában töltsük fel mintaalkalmazásunkat adatokkal!

Az alkalmazást futtatva (Az Application típus InitData és GetSalesData metódusainak egymás utáni hívásával) az alábbi eredményeket kapjuk:

(Az első oszlop a város neve, a második a teljes, a harmadik oszlop pedig az átlagos rendelésállomány).

Egy nagyobb alkalmazás esetében nem egy ilyen kis üzleti funkciót kell elkészítenünk, hanem általában néhány tucatot, esetleg nagyságrendekkel többet. Minden olyan megvalósítás, amely egy-egy funkció megvalósításához extra programsorokat ad hozzá, hatványozottan jelentkezik ha egy egész halom üzleti funkcióról van szó.

A legtöbb fejlesztőcsapat eljut odáig, hogy a gyakran előforduló — több kódsort igénylő, összetett — adatlekérdezési, feldolgozási tevékenységekhez, alapfunkciókhoz újrahasznosítható kódkönyvtárat készít és azt használja az üzleti funkciók megvalósítása során.

A System.Linq névtér használata

A Microsoft mérnökei Anders Hejlsberg és Don Box irányításával a LINQ projekt keretében elkészítették az újrahasznosítható kódkönyvtárat —emellett még számtalan egyéb fontos technológiai elemet is —, amelyet a lekérdezések során használhatunk. Figyelem: nem lehet eléggé hangsúlyozni, hogy ez csak a projekt egyik eleme! Bár a LINQ-et mindenki a .NET 3.5-tel köti össze, fontos tudnunk, hogy az elkészült kódkönyvtárat akár a .NET 2.0-val és a Visual Studio 2005-tel együtt is használhatjuk.

Az említett funkciók a System.Core.dll-ben, a System.Linq névtérben találhatók. A funkciókönyvtár definiálja az ún. „standard query operators” absztrakt fogalomrendszert és erre építi fel az adatlekérdezések, adatfeldolgozások szemantikáját. Az operátorok között megtaláljuk a rendezést, kiválasztást, csoportosítást, projekciót és a különböző aggregációkat, illetve ezek kombinációit. Az operátorok alapvetően az ún. delegate típusok és iterátorok (IEnumerable leszármazottak) segítségével működnek.

A Visual Studio 2005 és a .NET 2.0 segítségével elkészítettem a GetSalesInfo olyan változatát, amely a System.Linq névtér típusait használja a jelentés elkészítésére:

Hát bizony, az eredmény — fogalmazzunk így — „érdekes”. A lekérdezés előállítására használt kódkönyvtár nem eredményezett olvashatóbb kódot, mint a korábbi „kézi” változat. A kódot jobban megnézve még az is kiderül, hogy a feldolgozás során egy CityOrder nevű típust is felhasználtam, amely az egyes városokhoz kapcsolódó megrendeléstételeket tartalmazza:

A kód intenzíven használ névtelen delegate típusokat, amelyek tulajdonképpen a lekérdezéshez tartozó néhány elemi műveletet definiálják. A kódot megfigyelve észrevehetjük, hogy abban nem szereplenek ciklusok, ellenben találunk egy Enumerable osztályt, amelynek olyan nevű műveleteit használjuk, mint például Join, GroupBy, Count, Sum, stb.

Ha ezen a ponton az Olvasót arról igyekezném meggyőzni, hogy „ugyan hosszabb és nehezebben olvasható ez a mintapélda, de a megoldás szép...” valószínűleg sokan javasolnák az elmeorvos mihamarabbi felkeresését.  Nem szeretnék orvoshoz menni, és igyekszem megmutatni, hogy a fenti megoldás most még ugyan frusztráló, de a szépség igenis „előrángatható” belőle...

A C# 3.0 használata

Lehet, hogy a fenti a fenti System.Linq névteret használó megoldásban azért ilyen csúnya, mert a LINQ projektcsapat ilyen „gyatra” megoldást „kalapált össze”? Nem, erről szó sincs... Ha itt és most megnéznénk, pontosan hogyan is működik ez a megoldás —de ezt itt most nem tesszük —, felismernénk, hogy letisztult  és alapvetően szép elgondolás áll a háttérben. Akkor vajon mégis mi frusztrál bennünket a példa kapcsán?

A megoldás elemei rengeteg ún. „szintaktikai zajt” tartalmaznak. Ezek közül a legjellemzőbb az, hogy rengeteg névtelen delegate típust használ, amelyek leírásánál bizony sok olyan ismétlődő, a leírásmód kapcsán valójában értéktelen dolog van, amelyet egyszerűen csak a C# nyelv szigorú szintakszisa követel meg. Az alábbi részletben kiemelt színnel jelöltem meg azokat a kódrészleteket, amelyek értéket hordoznak, a többi ebben az értelemben a „szintaktikai zaj” része.

Ezt a fontos tényt a LINQ csapat már a projekt elején felismerte és hozzákezdett a C# nyelv elemeinek olyan bővítéseihez, amelyek segítenek ezt a zajt jelentős mértékben csökkenteni, illetve ahol lehetséges, teljesen eltüntetni.

Az Architektúra Fórumon (http://.architekturaforum.hu) korábban publikált ciksorozatomban összegyűjtöttem és részletesen bemutattam azokat a nyelvi újításokat, amelyek a C# nyelvben megjelentek. Ezeket egy összefoglaló cikkben is elhelyeztem, amelyek az alábbi linken érhetők el:

http://architekturaforum.hu/blogs/inovak/archive/2007/06/20/a-c-3-0-nyelvi-250-jdons-225-gai-a-teljes-v-225-ltozat.aspx

A fenti kódrészletet a C# 3.0 új nyelvi képességei közül a lambda kifejezések, bővítő metódusok és a lokális típusfeloldás segítségével egyszerűbb formára hozhatjuk[1]:

Na, ha ezt a kódot nézzük, már hihetőbben hangzik az, hogy „szép”. A fenti kód érdekessége, hogy tulajdonképpen ugyanarra az MSIL kódra fordul le, mint a korábbi „frusztráló” kódrészlet: a C# nyelvi újdonságai ténylegesencsak a szintaktikai zaj leszűrését végzik. Az itt lévő kódban az eljáráshívásokat láncolhatjuk, illetve még mindig vannak olyan „tartalékok”, amelyek a C# 3.0 nyelvi lehetőségeivel tudunk kezelhetünk, mint például a CityOrder típus kiváltása az ún. névtelen típusokkal:

Ez már nagyon SQL-szerűen néz ki! Ez a C# kód még mindig gyakorlatilag ugyanazt az MSIL kódot eredményezi, mint az előző két változat. Eljutottunk addig a pontig, ahová a LINQ projekt tervezői is eljutottak: nyelvi elemmé lehet tenni az SQL-szerű lekérdezéseket! És a nyelvbe ez a képesség valóban be is került[2]:

Ha ezt a lekérdezést hasonlítjuk össze a fejezet elején lévő SQL lekérdezéssel, akkor már érezhetjük, hogy miben is rejlik a LINQ ereje.

Hol járunk most?

Eddig megtudtuk a LINQ-ről, hogy nem csak egyszerűen mozaikszó, tartalma is van:

Ø  A LINQ új .NET típusok könyvtáraként jelenik meg, amelyek jelentős része a System.Core.dll assemblyben található a System.Linq névtérben.

Ø  A LINQ a C# (és a VB.NET) fordítókba beépülve SQL-szerű szintaktika használatát teszi lehetővé, amely a háttérben a LINQ részét képező objektumok kezelését végző kódra fordul.

Eddig még csak a jéghegy csúcsát láttuk. A felszín alatt további érdekes dolgok rejlenek...

Most, hogy már áttekintettük, hogyan is működik a .NET futtatókörnyezete, nézzük meg a keretrendszer egészének felépítését! A .NET fejlesztői szemmel több logikai rétegből épül fel, amelyeket a következő ábra foglal össze:

1.  A .NET keretrendszer logikai rétegei

A Common Language Runtime

A .NET-étege, amely közvetlenül az alkalmazás végrehajtásáért felelő a .NET-terminológiában a Common Language Runtime nevet viseli, amelyet magyarul talán a „nyelvfüggetlen futtatórendszer” kifejezés ír a legjobban le. A rövidség kedvéért én a továbbiakban a CLR betűszót fogom használni. A CLR logikailag két fontos részből áll:

Ø  Az ún. Common Type System – CTS (magyarul egységes típusrendszer)azokat a „natív” .NET típusokat definiálja, amelyek az alapjai a CLR működésének. A típusok definícióján túl megszabja együttműködésüket (pl. a konverziókat) és a metaadatok közötti megjelenés formáját is.

Ø  A .NET-nyelvek nem feltétlenül támogatják a CTS definiálta összes típust. Az egységes nyelvi sepcifikáció, azaz a Common Language Specification – CLS olyan szabályokat definiál és a típusok egy olyan részhalmazát, amelyek segítségével a fordítás során keletkező assemblyket garantáltan bármelyik .NET nyelvben felhasználhatjuk.

Fizikailag a CLR legfontosabb része az mscoree.dll fájl. Akkor jut szerephez, amikor az assemblyre hivatkozunk. Az mscoree.dll gondoskodik arról, hogy megtatlálja az assemblyt, betöltse, az assembly metaadatainak segítségével megtalálja benne a keresett típust, lefordítsa a megfelelő metódusokhoz tartozó MSIL-kódot, stb.

A Base Class Library

Ahhoz, hogy a CLR és a Win32 API-k szolgáltatásait ésszerűen és hatékonyan lehessen használni, rengeteg alapobjektumra szükség van, amelye a .NET nyelvek által jól használható objektumok köntösébe csomagolja a funkciókat. Ezt a célt szolgálja a .NET alapobjektumainak könyvtára (Base Class Library), amely logikailag számtalan módon felosztható. A .NET logikai rétegeit bemutató ábra csak néhány fontos elemet ragad ki ezekből. Számtalan olyan osztály, illetve szolgáltatásterület van, amely ezen az ábrán nem szerepel.

Az alaposztályok könyvtárát sok különálló assembly alkotja. Közülük a legfontosabb az mscorlib.dll fájl, amely a leggyakrabban használt típusokat tartalmazza, illetve az általános programozási feladatok megoldása során hasznos funkciókat. Amikor egy .NET-t vagy komponenst készítünk, az mscorlib.dll assemblyt mindig használjuk.

A Base Class Library valódi szerepe az, hogy ún. infrastrukturális szolgáltatásokat kínál a fejlesztőknek, vagyis olyan szolgáltatásokat, amelyek segítségével az operációs rendszer funkcióit reprezentáló Win32 API felett egy könnyen, jól és biztonságosan használható felületet kapunk. Bármilyen alkalmazás-architektúrában is gondolkodunk, az egyes architektúrarétegek mindegyike biztosan fel fogja használni a Base Class Library szolgáltatásait.

A .NET architektúra szolgáltatásai

A .NET keretrendszer más az első változataitól kezdődően a fejlesztők számára nemcsak infrastrukturális szolgáltatásokat kínált, hanem komoly architekturális szolgáltatásokat. Ezek olyan komoly értékkel és tartalommal bíró elemei a .NET keretrendszernek, amelyek a többrétegű[1] elosztott alkalmazások egyes architekturális rétegeinek megvalósítását segítik. Felhasználásukkal úgy építhetünk robusztus és skálázható architektúrát, hogy közben a .NET-környezet által kínált egyszerűséget és rugalmasságot megtarthatjuk.

A szolgáltatások önmagukban olyan terjedelmesek, hogy mindegyikhez könyvtárnyi irodalom tartozik. Ebben a cikkben én csak egy rövid áttekintésre vállakozom, kiemelve a legfontosabbakat.

Ø  ASP.NET: Az ASP.NET a webes alkalmazásfejlesztés alapvető eszköze a .NET keretrendszeren belül, amely több jól elhatárolt architektúraréteg elemeinek, komponenseinek megvalósítását támogatja a felhasználói felület és felhasználói folyamatok rétegének kialakításától egészen a webszolgáltatásokra épülő üzleti homlokzatok kialakításáig. Maga az ASP.NET talán a .NET keretrendszeren belül az egyik legösszetettebb architekturális szolgáltatás.

Ø  WinForms: Minden vastag kliens alkalmazás készítése során szükség van dialógusok, űrlapok, üzenetek megjelenítésére, amelyek egyszerű és összetett felhasználói felületelemeket egyaránt tartalmazhatnak. A .NET a WinForms eszköztárat kánálja erre a célra. A WinForms objektumhierarchiája segítségével egyszerűen kezelhetjük a vastag kliens alkalmazásokhoz tartozó felületelemeket, egyszerű leszármazással létrehozhatunk új vizuális komponenseket.

Ø  Webszolgáltatások: A szoftvertechnológiák kialakulása során mindig fontos szerepet kaptak azok, amelyek a platformok és a rendszerek meglévő rendeltetéseinek integrálását célozták meg. A webszolgáltatások használata napjainkban a legfontosabb technológia rendszerek — akár platformok között átívelő — integrálására. Annak, hogy a technológia elfogadottá, illetve szabvánnyá vált — úgy gondolom — jelentős szerepe van a .NET-nek, amely ennek a technológiának a használatát nem csak elérhetővé, de egyúttal igen egyszerűen használhatóvá is tette.

Ø  ADO.NET: A Microsoft az elmúlt 15 évben rengeteg módon próbálta meg az adatelérést, mint infrastrukturális szolgáltatást megteremteni. Ennek a legletisztultabb formája az ADO.NET-ben jelenik meg, amely szabványos felületet adó relációs adatbázisok és egyéb strukturált adatok elérésére (ún. ADO.NET providereken keresztül) és az ott található adatok egységes, az adatforrástól független reprezentációjára (az ún. DataSet-ek segítségével). Az ADO.NET egyszerű és áttekinthető modelt kínál az adatok lekérdezésére és adatbázisokba való visszaírására egyaránt.

Ø  Workflow Foundation (WF): A .NET 3.0-ban megjelenő Workflow Foundation a munkafolyamatok definiálását, végrehajtását és kezelését segítő infrastrukturális szolgáltatások — mint a neve is mutatja — alapjait teszi le. Lehetőséget nyújt ún. szekvenciális (a folyamat tevékenységeit időben egymást követő elemek hálójaként írjuk le), illetve állapotgépalapú (a folyamatot egy véges állapotú, események által vezérelt gépként írjuk le) munkafolyamatok kezelésére. A kialakítása kapcsán egyaránt használható humán és automatikus folyamatok leírására. A WF nem munkafolyamat-motor, jelen állapotában sok olyan szolgáltatás hiányzik belőle, amelyet azok általában megvalósítanak.

Ø  Windows Communication Foundation (WCF): A .NET-ben a kezdetek óta ott vannak azok az infrastruktúra szolgáltatások (például .NET remoting, webszolgáltatások, üzenetsorkezelés), amelyek elosztott rendszerek komponensei között a kommunikációr biztosítják. Ezek közül egy adott feladat, rendszer kapcsán az implementáció során mindig ki kellett a fejlesztőnek választania azt, amely az adott feladathoz a legjobban illeszkedik. A .NET 3.0-ban megjelenő Windows Communication Foundation egységes megoldást ad az elosztott rendszerek közötti kommunikációra korábban használt szétágazó megoldásaira. Lehetővé teszi a kommunikációs csatorna viselkedésének és futásidejű tulajdonságainak kialakítását a rendszerek újrafordítása nélkül, pusztán konfigurációs változtatások segítségével.

Ø  Windows Presentation Foundation (WPF): A Vista tervezésekor a Microsoft újraértelmezte a számítógépek grafikus alrendszerének fogalmát és egy olyan megoldást alkotott, amely maximálisan ki tudja használni a grafikus processzorok képességeit. Ennek kapcsán született meg a Vistában megjelenő, illetve a .NET 3.0 részeként is elérhető Windows Presentation Foundation, amely a régi vastag kliens felhasználói felület koncepciót „kihajítva” egy teljesen új koncepciót és az erre illeszkedő fejlesztési modellt foglal magában. A WPF segítségével fizikailag is elválaszthatóvá válik a képernyőn lévő vezérlőelemek vizuális megjelenése, illetve viselkedése. Lehetővé válik, hogy a programozási tapasztalatokkal bíró fejlesztő csak a vezérlőelemek viselkedésével (funkcionalitásának biztosításával) foglalkozzon, a megjelenését pedig grafikus, illetve designer alakítsa ki.

Ø  CardSpace: A Microsoft már régóta dolgozik ún. „Identity Metasystem” koncepcióján, amely valójában a digitális azonosítók tárolásának, kezelésének egy platformja. Ennek a koncepciónak a része a .NET 3.0 részeként elérhető CardSpace, amely a digitális azonosítók biztonságos tárolására szolgál. Ma már mindegyikünk számtalan  digitális azonosítóval rendelkezik: gondoljunk csak arra, hány webhelyen is rendelkezünk regisztrációval. A CardSpace természetesen nem csak ezeknek az azonosítóknak a tárolását végzi, hanem egységes felületet is nyújt egy adott művelethez, tranzakcióhoz (pl. bejelenkezés egy adott webhelyen, azonosítás elektronikus vásárlás során) tartozó digitális azonosító kiválasztásához.

Ø  Entity Framework: A .NET 3.5 változatához kapcsolódó ADO.NET v3.0 jelentősen túl lép az adatkezelés korábban használt eljárásain. Az ADO.NET  korábbi változatai elsősorban a relációs adatbáziskezelők fölé emeltek egy olyan absztrakciós réteget, amely lehetővé tette, hogy az ott található adatokat a fizikai adatbáziskezelőtől független objektumokként (DataSet és társai) láthassuk, használhassuk. Az Entity Framework ezt az absztrakciót fogalmi (koncepcionális) szintre emeli. ORM[2] technológiák segítségével lehetővé teszi, hogy az adatbázisainkban ne egyszerűen táblákat és közöttük lévő relációkat lássunk, hanem olyan magsszintű entitásokat, amelyek jól illeszkednek alkalmazásaink fogalmi modelljéhez. A jelenlegi információk szerint az Entity Framework a Visual Studio 2008 után fog megjelenni, várhatóan 2008 első félévében.

Egy-egy új .NET változat megjelenése általában a keretrendszer mindegyik logikai rétegében újdonságokat, változtatásokat kínál. A .NET 1.1-es és 2.0-ás változata elsősorban az infrastruktúra szolgáltatásokat bővítette, finomította. A 2.0-ás változat A WinForms és ASP.NET technológiákat már valódi architekturális szolgáltatásokká tette. A .NET 3.0 gyakorlatilag „csak” architekturális változtatásokkal bővítette a keretrendszert. A jövöben megjelenő .NET keretrendszerek várhatóan szintén elsődlegesen újabb architekturális szolgáltatásokkal fogják bővíteni a fejlesztők eszköztárát.