A cikk első részében megvizsgáljuk miért volt szükség a .NET bevezetésére, megismerjük az .NET tervezőit vezérlő alapgondolatokat és áttekintjük a .NET Framework felépítését. //-->

5 perc .NETológia

.NET egy olyan témakör, amihez csak fokozatosan közeledhetünk. Éppen ezért egy webcikk nem a legalkalmasabb hely a .NET-tel való ismerkedésre és inkább csak étvágygerjesztő vagy ízelítő szerepet játszhat. Jelen cikket is így kell felfogni: sok mindenről lesz szó, a részletek elmagyarázása azonban nem lehet célja egy ilyen bevezetőnek. Ha a cikk elolvasása után a kedves Olvasó úgy fogja érezni magát mint az a turista, aki türelmesen végighallgatta az idegenvezető magyarázatát és az utazás végén úgy érzi, hogy a látottak kissé összekavarodtak emlékezetében, de azért világosan emlékszik egy-két fogalomra és elhatározza, majd utánanéz a dolognak egy pár szakkönyvben és legközelebb egyedül indul felfedezőútra - akkor ez a cikk elérte célját.

Kezdjük hát el utazásunkat és én is, ugyanúgy mint az avatott idegenvezető, röviden összefoglalom a megismerésre váró táj, a .NET történetét.

Az elején volt a DOS, egy nagyon sikeres operációs rendszer személyi számítógépek részére. Az ipar hamar elfogadta a DOS-t mert lehetővé tette egyszerű bemeneteli felületek programozását, amire az iparnak nagy szüksége volt. Így sok üzleti folyamatot automatizálni lehetett.

Egy grafikus felület hiánya azonban gátolta a PC terjedését. Parancsvonalon utasításokat kellet beadni és ez csak „szakemberek” részére tette a PC-t élvezhető munkaeszközzé. Az idő megérett egy minőségi változásra. Microsoft egy új operációs rendszerrel, a Windows-szal látta el a számítógépeket. Az elején Windows csak egy kiterjesztése volt a DOS-nak, későbbi verzióiban egy tényleges önálló rendszerre nőtte ki magát.

Windows magával hozta a Windows API könyvtárakat, melyek a rendszerprogramozást ugrásszerűen megkönnyítették. A grafikus felhasználófelülettel (graphical user interface, GUI) rendelkező programok száma a felhasználók számával együtt rohamosan nőtt

Miután a PC-piacon Microsoft addig elképzelhetetlen sikereket könyvelhetett el, ismét egy újításra szánta el magát: a Unix által dominált szervervilágot készült meghódítani. Microsoft fejlesztői számára világos volt, hogy ezt nem lehet egy 16 bites rendszerrel megkísérelni, ezért létrehozták a Windows NT 32 bites rendszert. Az új Windows platform a 16 bites API rutinokat a Win32 API rutinokkal helyettesítette. A régi alkalmazásokat át kellet írni az új környezetre, de a befektetett munka és tőke kifizetődött. A 32 bites alkalmazások biztonságosabbak, gyorsabbak és stabilabbak voltak, mint a 16 bites testvérei.

Az alkalmazások robbanásszerű megnövekedésével életfontosságúvá vált bizonyos programrészek, úgynevezett komponensek többszöri felhasználásának lehetősége. Erre a kihívásra Microsoft válasza a COM (Component Object Model) technológia volt. A COM technológiával előregyártott forráskódot bináris formában, a DLL könyvtárak alakjában, többször is fel lehet használni. A COM technológia az objektum-orientált programozásra (OOP) alapszik és itt látjuk a nyelvsemlegesség első megnyilvánulásait. Ugyanis hamar természetessé váltak a Visual Basic alkalmazások., melyek C++-ban írt COM-alapú DLL-eket használtak.

A kilencvenes évek vége felé járunk, mikor a Microsoft felelősei kénytelenek egy konkurens technológia sikerét figyelembe venni. Sun Microsystems Java-járól van szó. Java sok mindenben hasonlít a COM-ra. Ugyanúgy mint a COM, a Java komponensalapú programozást jelent. Ugyanakkor viszont, Java egy jó pár igen fontos előnnyel rendelkezik a COM technológiával szemben. Legelőször is Java olyan OOP lehetőségekkel rendelkezik, amelyek hiányoznak a COM technológiában: statikus metódusok (static methods), metódusok felülírása (method overloading), parametrikus konstruktorok (parametrized constructors), öröklés (inharitance) és strukturált kivételkezelés (structured exception handling). Java egy gazdag osztálykönyvtárat bocsát a fejlesztő rendelkezésére, amit objektumorientált API rutinokkal lehet elérni. A Java alkalmazások platform-független alakra lesznek lefordítva és futásukról egy virtuális gép gondoskodik.

Mindez döntésre késztette Microsoftot: az idő megérett egy új stratégiai döntésre. 1997-ben a PDC-n (Programmers Developers Conference) Microsoft elsősorban a COM és COM+ technológia jövőjével foglalkozott és megfogalmazta az új követelményeket: nyelvsemlegesség, alaptípusok, objektumorientáltság. Mint látni fogjuk, ez a döntés egy új technológiához vezetett és egyúttal a COM/COM+ technológia végét is jelentette. Kellett ez nekünk? - tehetjük fel a jogos kérdést. A válasz egyértelmű: Igen! A mostanáig használt COM/COM+ rendszerplatform nem felel már meg a modern, többrétegű, webalapú alkalmazások kihívásának. Microsoft tanult a Java sikeréből és megértette, hogy eljött az idő, amikor nem csak megjelenésükben, de fejlesztésükben is a win- és a webalkalmazások közti különbséget meg kell szüntetni vagy legalábbis a minimálisra csökkenteni.

Az ezredfordulóra megszületett az új technológia, a .NET.

A .NET alapelvei

Végül is mi a .NET?

Röviden: a .NET (olvassuk „dotnét”) egy Microsoft technológia, mely lehetővé teszi alkalmazások, programok és szolgáltatások nyelv-, rendszer- és platformsemleges felépítését. Nyelvsemlegesség alatt nem csak azt értjük, hogy a kitűzött feladat megoldását bármelyik .NET-nyelvvel elérhetjük, hanem azt is, hogy különböző nyelveken kódolt modulokat zökkenőmentesen összekapcsolhatunk egy .NET alkalmazáson belül. A .NET rendszersemlegessége biztosítja .NET alkalmazások futását minden olyan rendszer alatt, mely rendelkezik a .NET futáskörnyezetével, ezt pedig elvileg minden rendszer részére elkészíthető. A platformsemlegesség alatt pedig azt értjük, hogy például egy Web alkalmazás esetében mindegy, hogy egy PC-böngészőben, egy mobil készüléken vagy egy PDA-n hagyjuk futni, az eredmény lényegében ugyanaz.

A következőkben felsorolom a .NET alapelveit. Ha az alábbi felsorolás nem hoz világosságot a fogalmak dzsungelébe, akkor ne veszítsük el a reményt, hogy a dolgok lassan körvonalazódni fognak. A felsorolás után megkísérlem a fogalmakat érthetően elmagyarázni. A .NET megértése szoros összefüggésben áll eddigi programozási tapasztalatunkkal. Aki már programozott Java alkalmazásokat vagy aki otthonosan mozog a Visual Basic komponensek előállításában vagy netán részt vett többrétegű alkalmazások fejlesztésében, az sok mindent kapásból megért. Aki mostanáig csak a tradicionális programozásba mélyült el és nem, vagy csak nagyon ritkán folyamodott az objektumorientált programozás adta lehetőségeihez, az a .NET megismerésével alapvetően új gondolkodási és kódolási módszerekkel kell megismerkedjen és erre idő és sok gyakorlat szükséges. A fáradság viszont megéri.

Tapasztalatom szerint a .NET elsajátításának görbéje az elején nagyon „lapos” és csak egy idő után lesz igazából meredek. Ekkor azonban, sok mindent, amit azelőtt csak nagy fáradsággal és költséges befektetéssel értünk el, gyorsabban, biztonságosabban és hatékonyabban tudunk megvalósítani.

A .NET-et kísérő fő gondolatok tehát a következők:

  •     .NET több részből áll. Ezekhez tartozik a .NET Framework munkakeret sok-sok osztálykönyvtárral, melyek a .NET-nylevek rendelkezésére állak, fordítók (compilers) és más eszközök, mint a disassembler. Ide tartozik továbbá az ADO.NET, az ADO utódja, valamit az ASP.NET, az ASP utódja. Ide számítható a .NET legelső alkalmazása is, a Visual Studio .NET.
  •     A .NET programozás nem követeli meg a Visual Studio .NET telepítését a gépünkre. Csak a .NET Framework SDK-ra van szükségünk, amit viszont ingyen letölthetünk. Igaz ugyan, hogy legalább 130 MB-ről van szó, de az SDK-t CD-n is meg lehet rendelni. Pillanatnyilag az 1.0 és az 1.1 verzió között választhatunk. A .NET Framework SDK a dokumentáció mellett a parancsvonal fordítókat (command line compilers) is tartalmazza, így elvileg akár a Jegyzettömbbel (Nodepad) is programozhatunk .NET alkalmazásokat. Természetesen a Visual Studio .NET fejlesztőrendszer használata sokkal kényelmesebb, ellenben nem egy olcsó dolog: legolcsóbb variánsa egy pár száz dollárba kerül. Ez nem egy akadály a .NET technológia megismerésében: .NET alkalmazások fejlesztésére nagyon hatékony ingyenes fejlesztőrendszerre tehetünk szert, sőt akár ingyenes tárterülethez is hozzájuthatunk .NET webszerveren, erről azonban később még szó lesz.
  •     A .NET elvileg független a programozási nyelvtől. Eredetileg Visual Basic.NET, C++ és az új C# ( c sharp, olvasd szísárp; én szívesebben használnám ennek a hangnemnek a magyar megfelelőjét: cisz) nyelveket támogatta. Most több mint tíz nyelven lehet .NET programokat írni és a .NET-re szabott nyelvek száma állandóan nő.
  •     A .NET elvileg nem követel egy bizonyos operációs rendszert. Megfelelő .NET futáskörnyezet vagy üzemkeret (runtine framework) létezik Windows 9x, Windows NT 4.0, Windows 2000/XP rendszerek részére. Nemsokára Windows CE és Pocket PC számára is elkészülnek a .NET üzemkeretek. A Unix és Linux részére is készülnek már a .NET verziók.
  •     A .NET osztályok a Win32 API osztályokat helyettesítik, pillanatnyilag mintegy 95%-ban. A .NET a COM és részben a COM+ komponenseket is helyettesíti és ugyanakkor egy magas interkompatibilitás arról gondoskodik, hogy a COM/COM+ komponensek simán beágyazhatók legyenek a .NET alkalmazásokba és hogy, fordítva, a COM/COM+ alkalmazások .NET modulokat használhassanak.
  •     .NET támogatja az alkalmazások és komponensek egymásmelletti (side-by-side) végrehajtását. Ez azt jelenti, hogy egy és ugyanannak a komponensnek vagy alkalmazásnak különböző verziói egyszerre ugyanabban az időben és, ha szükséges, ugyanabban a folyamatban (process) hajthatók végre anélkül, hogy ez konfliktushoz vezetne. Ezzel Microsoft egy nagy lépést tett a DLL pokolból (DLL-hell) való kiszabadulás felé.
  •     A .NET „szíve” egy virtuális gép, mely kezelt vagy menedzselt kódot (managed code) hajt végre. A menedzselt kód olyan programkód, melynek együttműködése a futáskörnyezettel (Common Language Runtime, CLR) pontosan szabályozva van. A .NET fordítók menedzselt kódot produkálnak.
  •     A .NET, programozási nyelvtől függetlenül, egy és ugyanazt a futáskörnyezetet használja.
  •     A .NET a Common Type System (CTS) segítségével egy egységes adattípuskészletet határoz meg, amit mindegyik .NET-nyélv köteles használni. A CTS adattípusokon túl, a .NET-nyelvek sajátos adattípusokat is használhatnak, használatuk viszont szigorúan szabályozott.
  •     A .NET alkalmazások és komponensek önmeghatározók. Az alkalmazások és komponensek mindig magukkal hordják a metaadatokat, melyeket a futáskörnyezet mindig lekérdezhet. Éppen ezért egy .NET alkalmazást nem kell regisztrálni. Elegendő ha az alkalmazás futásához szükséges adatokat és állományokat egy mappába másoljuk és így adjuk át annak a gépnek, amelyikre az alkalmazást telepíteni kívánjuk. A „telepítés” ismét olyan egyszerű mint a hős DOS-korszakban: telepíteni = másolni és természetesen leinstallálni = törölni. Mivelhogy az alkalmazás „tudja” milyen adatokra van szüksége és a futáskörnyezet biztosítja ezeket az adatokat, nem állhatnak elő konfliktusok, ha ugyanaz az állomány több verzióban rendelkezésre áll.
  •     A .NET fordítók egy közkódot vagy közbülső kódot hoznak létre, az Intermediate Language-et (IL). Közvetlenül az alkalmazás végrehajtása előtt ez a közbeeső kód gépkódra lesz átalakítva. Ezért, a .NET alkalmazások platformfüggetlenek.
  •     .NET rendkívül gazdag osztálykönyvtárakat bocsát a programozók rendelkezésére. Ezek az osztálykönyvtárak az operációs rendszer API rutinjait hivatottak helyettesíteni. Ezek az osztályok nemcsak a rendszerspecifikus műveletekre, de az adatbázisok kezelésére, az XML-állományok kezelésére és a hálózat programozására is illetékesek.
  •     A .NET komponenseket a felhasználó program nem távolítja el a memóriából. Pontosabban fogalmazva, a .NET komponensek a COM komponensekkel ellentétben nem rendelkeznek egy Terminate eseménnyel. Ezzel szemben a .NET futáskörnyezet egy összrendszerű (systemwide) hulladékgyűjtővel (Garbage Collector, GC) rendelkezik, mely szabályos időközökben gondoskodik a már nem szükséges erőforrások felszabadításáról.

A .NET architektúra

.NET madártávlatból

A .NET vázlatos felépítését az alábbi ábra szemlélteti. Az ábrán könnyen felismerhetjük a .NET architektúra főbb elemeit.


A .NET vázlatos felépítése

Az operációs rendszer a Common Language Runtime (CRL) futáskörnyezeten keresztül kerül a :NET-tel első érintkezésbe. Ez a futáskörnyezet teszi lehetővé, hogy a .NET alkalmazások nyelv-, rendszer- és platformfüggetlenek legyenek. A .NET alaposztályai és az adatok és XML objektumok kezelésére szakosított osztályok helyettesítik az eddigi API rutinokat. Ezeket az osztályokat egyenlően használhatják úgy a winalkalmazások mint a webalkalmazások. Erről a specializált win- illetve web-szolgáltatások gondoskodnak. Az alkalmazásokat akármelyik .NET-nyelven, egy bizonyos fokig akár keverve is, fogalmazhatjuk meg. Ezt a nyelvi indifferenciát a Common Language Specification (CLS) biztosítja. A COM/COM+ és .NET közti kompatibilitást a COM/COM+ interfész teszi lehetővé.

E gyors áttekintés után, a következő részben a .NET főbb komponenseivel foglalkozunk.

Common Language Runtime (CLR)

A Commom Language Runtime (CLR) az új futáskörnyezet, melyet mindegyik .NET-nyelv használ. Ha a CLR egy gépen jelen van, akkor mindegy melyik .NET-nyelvet használtunk az alkalmazás fejlesztésekor, és ugyanilyen lényegtelen, hogy melyik operációs rendszer alatt fejlesztettük az alkalmazást - az alkalmazás minden nehézség nélkül futni fog a gépünkön. Ennek óriási hatása van a fejlesztők munkájára: teljes erővel a feladat megoldására koncentrálhatnak és nem kell gépspecifikus kérdésekkel foglalkozniuk. A CRL a megfelelő .NET üzemkerettel együtt kerül a gépre, ez pedig egy egész sor operációs rendszer részére már létezik.

A CLR által végrehajtható kódot menedzselt vagy kezelt kódnak nevezzük. Azért beszélünk menedzselt vagy kezelt kódról, mert a CLR ténylegesen menedzseli vagy kezeli a kódot: a forráskód minden információt arról amire szüksége van, magába hordoz és a CLR, miután a kódból kiolvasta ezt az információt, az alkalmazás rendelkezésére bocsátja a szükséges erőforrásokat. VB.NET és C# fordítók mindig menedzselt kódot produkálnak, míg a C++ fordító csak akkor, ha a nyelv menedzselt bővítését használjuk. Bizonyos értelemben a CLR szerepe hasonlít a JVM-re (Java Virtual Machine) és a VB6 futáskörnyezetére, mely p-kódot hajt végre. A lényeges különbség abban áll, hogy CLR felordítja a neki átengedett kódot. A .NET fordítók nem gépkódot produkálnak (mit a C/C++ esetében) vagy bájtkódot (mit a VB p-fordítója vagy a Java esetében), hanem egy másik nyelvre fordítanak, az Intermediate Language-re (IL). Ez az IL kód kerül a CLR kezelése, menedzselése alá és csak mielőtt az IL kódot végrehajtaná, a CLR lefordítja gépkódra. Ez nevezzük just-in-time (JIT) fordításnak. A JIT fordítás azt is jelenti, hogy a CLR egy adott alkalmazás IL kódjából csak annyit fordít le, amennyire pillanatnyilag az alkalmazás végrehajtására szüksége van, A JIT eljárás hatalmasan megnöveli a .NET alkalmazások sebességét.

Itt úgy érzem még egyszer hangsúlyoznom kell, habár erre még visszatérünk: annak ellenére, hogy a .NET fordítók EXE- vagy DLL-állományokat állítanak elő, ezek nem tartalmaznak gépkódot, hanem IL-kódot!

A .NET fordítók az IL-re való fordítás mellett metadatokat helyeznek el a kódban, melyek a DLL- vagy EXE-állományokban használt adattípusokat írják le, nagyjából úgy, mint ezt a COM típuskönyvtárak esetében ismerjük, azzal a különbséggel, hogy ezúttal a kódverzióról és a különböző függőségekről is információ kerül az IL kódba. Ez az információ teszi lehetővé, hogy a CLR „intelligensen” menedzselje az IL-kódot és ugyanakkor nincs szüksége a Windows registry-re.

A CLR által nyújtott szolgáltatásokat három címszó alatt gyűjthetjük össze: kódellenőrzés (code verification), kódbiztonság (code access security) és hulladékgyűjtés (garbage collection).

A kódellenőrzés alatt CLR a kód helyességét vizsgálja meg. A CLR megvizsgálja az adattípusokat és a megcélzott memóriarészeket. Ha a kód tiltott műveletet készül elvégezni, CRL egy kivételt (exception) idéz elő, amit az alkalmazás fel tud dolgozni. Elméletileg, egy kellőképpen kivételkezeléssel ellátott .NET alkalmazás nem okozhat kárt a rendszerben.

A kódbiztonság lehetővé teszi, hogy az alkalmazás olyan jogosultsággal legyen felruházva, mely a gép biztonsági beállításától, a kód eredetétől és a kód meteadataitól függ. A CLR a kódbiztonsággal a rendszert megvédi a rosszindulatú alkalmazásoktól.

A hulladékgyűjtés automatikusan gondoskodik a memória kezeléséről. Eltérően a mostanáig használt nyelvektől, a .NET programozás során létrehozott és felhasznált osztályok példányit, azaz objektumokat, de nem kell megszüntetnünk. Ha a CLR egy objektumra vonatkozóan nem talál „élő” hivatkozást, maga gondoskodik az objektum eltávolításáról a memóriából. Hasonló dolgot látunk már a Visual Basic esetében, most viszont a szükségtelenül lefoglalt erőforrások felszabadítása eredményesebb. Egy lényeges különbség a mostanáig látott hulladékgyűjtőktől a folyamat non-determinisztikus jellege: nem mondhatjuk meg előre, mikor kerül egy erőforrás felszabadításra. Annyi biztos, hogy nem idő előtt. Ha azonban egy függvényben egy objektumot definiáltunk, a függvény lefutása után nem lehetünk biztosak abban, hogy az objektum máris el lett távolítva a memóriából.

Common Type System (CTS) és a Common Language Specification (CLS)

Azért, hogy a különböző .NET nyelvek között a közreműködés és kommunikáció zökkenőmentesen megtörténhessen, a CLR egy közös típusrendszerre (Common Type System), a CTS-re támaszkodik.

A hagyományos nyelvek úgynevezett primitív típusokkal rendelkeznek, ezek viszont csak ritkán kompatíbilisak egymás között: a C++ int, long és string típusai nem egyeznek meg 100%-an a VB6 Intger, Long és String típusaival. Aki már használt Win32 API rutinokat Visual Basic programban vagy már írt COM komponenseket, az tudja milyen sok gondot okoz az adattípusok inkompatibilitása és hogy milyen nehéz munka az adattípusok egymáshoz való illesztése. Mindezeket a nehézségeket elkerülendő, CLR megkövetel egy közös típusrendszert, a CTS-t.

A CTS 12 adattípusát (nagyon vázlatosan) a következő táblázatba foglaltam össze:

Adattípus Méret
bájtban
Boolean 4
Byte 1
Char 2
DataTime 8
Decimal 12
Double 8
Int16 2
Int32 4
Int64 8
Object 4
Single 4
String változó

A CTS típusai minden nyelvben jelen kell legyenek. Például a CTS Int32 típus VB.NET-ben Integer és C#-ban int típusnak fele meg. Ezenkívül a különböző nyelvek más típusokat is használhatnak: Ez így is van a gyakorlatban, ami viszont inkompatibilitásokhoz vezethet, mivelhogy előfordulhat, hogy az egyik nyelv sajátos típusát egy másik nyelv nem érti meg. Például C# ismeri az ulong típust, viszont VB.NET nem kezdhet semmit vele. Hogy a CLR mégis zökkenőmentesen dolgozhasson, az együttműködést szabályozni kell. Ez a szerepe a Common Language Specification név alatt ismert szabálygyűjteménynek, specifikációnak

A Common Language Specification (CLS) általános szabályokat fektet le, amelyeket minden .NET-nyelv be kell tartson. A CLS például nem engedi meg, hogy egy osztály nyilvános (public) tagja olyan típusú legyen, mely más nyelv számára ismeretlen, mert akkor az egyik nyelven írt osztályt a másik nyelv nem használhatja. Ugyanakkor megengedett, hogy ilyen, nem a közös adattípushoz tartozó, típusok az osztályok nem nyilvános tagjai legyenek

.NET osztály(könyv)tárak, névterek és osztályok

A CLR mellett a .NET második fontos részét az osztálykönyvtárak képezik. Az osztálykönyvtárak mindegyik .NET-nyelv rendelkezésére állnak. A .NET-en belül az osztálykönyvtárak logikai és funkcionális egységekbe vannak csoportosítva. Egy ilyen egységet névtérnek (namespace) nevezzünk.

A névterek nem kizárólagosan a .NET sajátossága. Névterekkel már a VB6-nál is találkoztunk, csak ott el voltak rejtve. Nem mindegyik VB programozó törődött sokat azzal, hogy Rnd() nem egy függvény hanem a Math osztály egy metódusa, mely a VBA komponenshez (értsd: névtérhez) tarozik. Azért fogalmazhatunk így:

r = Rnd()

mert VB6 induláskor „importálja” (jegyezzük meg ezt a kifejezést, még visszatérünk rá) a VBA névteret. Különben

r = VBA.Math.Rnd()

tökéletesen helyes, még akkor is ha senki sem kódol így. A FileSystemObject objektum esetében a dolgok nincsenek ennyire elrejtve. Ha nem tudatjuk VB6-tal, hogy a Scripting komponenst vagy névteret akarjuk használni (using, ezt a kifejezést is jegyezzük meg), azaz ha a projektünk nem hivatkozik a Scripting.FileSystemObject komponensre, illetve a scrrun.dll könyvtárra, akkor a következő deklaráció

Dim fs As Scriptiong.FileSystemObject

egy hibát idéz elő.

A .NET következetesen használja névtereket. A legfontosabbak a következők:

  • System    A leggyakrabban használt alaposztályokat, amelyek adattípusokat, eseményeket, eseménykezelőket, interfészeket, attribútumokat, kivételeket, stb. definiálnak.
  • System.Collection    Azokat az osztályokat és interfészeket tartalmazza, amelyek gyűjteményeket, listákat, sorokat, tömböket, indextáblákat és könyvtárakat definiálnak.
  • System.Data    Azokat az osztályokat tartalmazza, amelyek az ADO.NET-hez tartoznak.
  • System.Diagnostics    Azokat az osztályokat tartalmazza, amelyek a hibakeresők működését teszik lehetővé.
  • System.Drawing    A GDI+ grafikai csomag osztályait tartalmazza.
  • System.Globalization    Olyan osztályokat tartalmaz, amelyek kultúrafüggő információkat definiálnak: természetes nyelvvel, ország- és régióval, naptárral, pénznemmel, számformátumokkal és karakterláncok rendezési szabályaival kapcsolatos információkat.
  • System.IO    Olyan osztályokat tartalmaz, amelyek az irást/olvasást az adatfolyamokba/adatfolymokból és állományokba/állományokból támogatják.
  • System.Net    Az Internetet támogató osztályokat tartalmazza.
  • System.Reflexion    Azokat az osztályokat tartalmazza, melyek az interfészekről, az osztályokról, az adattípusokról szolgáltatnak információt.
  • System.Security    A CLR biztonsági rendszerét támogató osztályokat tartalmazza.
  • System.Threading    A többszálú programozást támogató osztályokat tartalmazza.
  • System.Web    A webalkalmazásokat támogató osztályokat, többek között az ASP.NET osztályait tartalmazza.
  • System.Windows    A winalkalmazásokat támogató osztályokat tartalmazza.
  • System.XML    Az XML-állományok kezelését támogató osztályokat tartalmazza.

A több mint 5000 osztályt természetesen senki sem képes megjegyezni. A gyakorlat hozza magával, hogy lassan-lassan megismerkedünk a legfontosabb névterekkel. A dokumentáció böngészése viszont mindegyik .NET-programozó mindennapi teendőjéhez tartozik.

.

NET-ben bármelyik nyelvén objektum-orientáltan tudunk programozni. Egyszerűen kifejezve: .NET-ben minden osztályokon alapszik, osztályokat definiálhatunk, osztályokból más osztályokat vezethetünk le, metódusokat felülírhatunk és/vagy felültölthetünk és áltatában, az OO-programozás minden lehetősége rendelkezésünkre áll. Egy ilyen bevezető írásnak nem lehet célja, hogy a részletekre kitérjen. A nemsokára bemutatásra kerülő példák egy keveset megvilágítanak az előbb említettekből, egy alapos tanulmányozás azonban elengedhetetlen. A cikk végén az érdekelt Olvasó egy pár útmutatást talál.

Új fogalmakat kell megtanulnunk: assembly, metadata, manifest

Már említettem, hogy a lefordított .NET alkalmazás egy *.exe vagy *.dll állományba kerül és hogy, habár bináris alakban van, nem gépkódot tartalmaz, hanem IL-kódot. Ezt az állományt nevezi a .NET együttesnek (assemby). A magyar szakirodalomban, amennyire én ezt innen megítélhetem, az együttes kifejezés nem terjedt el, annak ellenére , hogy tökéletesen fedi az angol assembly-t.

Mit rejt magában egy assembly? Az alábbi ábra vázlatosan szemlélteti egy *.exe, illetve egy *.dll állomány felépítését.


Az assembly belső szerkezete

Mint látható egy végrehajtható program és egy könyvtár assembly-je nagyon hasonlóak.

Az assembly első része fontos információkat tartalmaz az alkalmazásról: a neve, verziója, más assembly-től való függőségek, attribútumok és más fontos adatok ebben a részbe kapnak helyt. Ezt nevezzük az assembly manifesztumának vagy kiáltványának (manifest). Az assembly ezzel a résszel tudatja a CLR üzemkerettel, mire van szüksége a helyes működésére.

Az assembly második része a metadatokat tartalmazza. Itt az assembly osztályairól, programok esetében a programmodulokról, könyvtárak esetében a könyvtárinterfészről találhatók az adatok típusára vonatkozó információk.

Végül, az assembly utolsó rész a kimondott IL-kódot tartalmazza.

Tudom, hogy mindez most nagyom absztrakt, de egy kis türelmet kérek: nemsokára mindezt a gyakorlatban is látni fogjuk. Egyes Olvasóim esetleg azzal érvelnek, hogy ezeket a dolgokat nem is szükséges tudni ahhoz, hogy egy .NET programot írhassunk. Véleményem szerint ez csak részben igaz. Tényleg lehet kisebb-nagyobb programokat írni anélkül, hogy behatóan ismerjük azt, ami a kódunk „mögött” történik, de a folyamatok bensőséges ismerete nélkül, bármikor megoldhatatlannak látszó feladatok elé kerülhetünk. Ilyenkor csak az elmélet segít a döntésben. Nem hiszem, hogy létezett valaha egy sikeres színdarabíró aki ne ismerte volna a kulisszamögötti világot. A programozásban sincs ez másként - ez az én meggyőződésem!

Mindent újra kell tanulnunk?

Mindent újra kell tanulnunk? - hangozhat el a jogos kérdés.

Nem, de sok mindent meg kell tanulnunk, ha hatékonyan akarjuk a .NET-et programozni. Aki most kezdi el a programozást az bizonyos értelemben előnyben van: nem kell leszokjon sok elavult praktikáról, bizonyos eljárások elsajátításában eddigi tapasztalata nem fékezi. Aki mostanáig is programozott, annak egy másféle előnye van: meríthet eddigi tapasztalatából, sok mindent hamarabb ért meg. Bármelyik kategóriához is tartozna kedves Olvasom, egy dologról biztos lehet. A programozás jövője a .NET-el már elkezdődött.

Ennyi elmélet szükséges volt, hogy megértsük, miben új és más a .NET technológia a klasszikus programozással szemben. Most azonban eljött az idő, hogy gyakorlatban is megismerjük a .NET programozást. E következő részek a .NET programozással folglalkoznak.