Aligha képzelhető el egy komolyabb webalkalmazás, mely ne jelenítene meg adatokat. Sőt, joggal állíthatjuk, hogy egy webalkalmazás lényege a legkülönbözőbb adatforrásokból nyert adatok megjelenítése és kezelése. Az adatokat szolgáltató források a legkülönbözőbbek lehetnek: elkezdve egyszerű változóktól és gyűjteményosztályoktól (collection class), az XML dokumentumokon keresztül, egészen az adatbázisokig.
Az adatelérés elmélete
Az ADO.NET a .NET technológia adatelérési és adatkezelési része. Az ASP.NET teljes hozzáférést biztosít az ADO.NET-hez, ami hatalmas kihatással van a webalkalmazások hatékonyságára. Az ADO.NET technológia részletes tárgyalása túlhaladja ennek a cikksorozatnak a kereteit. Itt csak az ADO.NET alapkérdéseivel foglalkozunk.
Az adatkezelő .NET alkalmazások natív .NET adatszolgáltatók (data provider) és az ADO.NET adatkezelő csomag közvetítésével érik el és kezelik az adatokat. Ez a módszer a leghatékonyabb, de ugyanakkor, koncepciójából eredendően, nem minden esetben a legalkalmasabb. Ugyanis minden relációs adatforrásnak saját .NET adatszolgáltatóval kell rendelkeznie. A 8.1 ábra felvázolja a natív .NET adatszolgáltatókat használó alkalmazások működését.
Sajnos nem mindegyik relációs adatforrás rendelkezik natív .NET adatszolgáltatóval. Még abban a szerencsés esetben is, amikor rendelkezésünkre áll egy natív .NET adatszolgáltató, az adatcsere két különböző adatforrás között nagy kihívást jelent a fejlesztő részére, mivelhogy mindegyik adatforrás, más- és másféle adatelérést és adatkezelést igényel. Ezekből a nehézségekből kiindulva született meg az egyetemes adatelérés gondolata.
A Universal Data Access (UDS), magyarul az egyetemes adatelérés, egy Microsoft stratégia, melynek célja az adatok nagyteljesítményű elérése az adatforrás milyenségétől függetlenül.
Az első lépést e büszke cél elérésére a Microsoft fejlesztői az adatbázisok egységes kezelésében látták. Függetlenül attól, hogy az adatok egy Access, SQL Server, Oracle, DB2 vagy MySQL adatbázistól erednek, hogyan lehet ezeket az adatokat egységesen elérni és kezelni? A választ erre a kérdésre az 1992-ben elfogadott Open Database Connectivity (ODBC) szabvány adja meg.
Az ODBC értelmében az adatfeldolgozó alkalmazások és az adatkezelő rendszerek (Database Management System, DBMS) nem közvetlenül kommunikálnak egymással, hanem egy közéjük elhelyezett rétegen keresztül, mely az ODBC meghajtónak (ODBC driver) ad helyet. Ha az adatfeldolgozó alkalmazás és az adatkezelő rendszer ezt lehetővé teszi, akkor ODBC-alapú (ODBC conform) adatkezelésről beszélünk.
ODBC-alapú adatkezelés esetén a kliensalkalmazások egy és ugyanazzal az utasításkészlettel dolgoznak, függetlenül attól, hogy melyik ODBC-alapú adatkezelő rendszertől nyerik az adatokat. Az ODBC-alapú adatkezelést a 8.2. ábra szemlélteti.
8.2 ábra. Az ODBC-alapú adatkezelés felépítése
Az ábrán láthatjuk, hogy a különböző relációs DBMS adatkezelők megfelelő ODBC meghajtókon keresztül kommunikálnak az ODBC.NET adatszolgáltatóval. Ezen a szinten történik az adatkezelés egységesítése. Az ODBC.NET adatszolgáltató biztosítja a kliensalkalmazás részére az egységes csatlakozási felületet (interface). A kliensalkalmazás az ADO.NET-en keresztül egységesen éri el és kezeli a különböző eredetű adatokat.
Az ODBC-alapú adatkezelés megoldja a relációs adatok egységes elérésének és kezelésének a kérdését. A gyakorlat azonban megmutatta, hogy nem elegendő az egyetemes adatelérést relációs adatokra korlátozni. Számtalan nem relációs adata forog a világban, melyek mennyisége talán meghaladja a relációs adatok mennyiségét. Gondoljuk csak a rengeteg hierarchikus adatra, mint például az XML vagy a CSV adatokra, az elképzelhetetlen számú Office dokumentumokra, stb. Mindezek az adatok nem relációs adatok és így nem érhetők el ODBC alapon.
8.3 ábra. Az OLEDB-alapú adatkezelés felépítése
Az egyetemes adateléréshez vezető úton a következő állomás az OLEDB-alapú adatelérés, amit a Microsoft 1997-ben vezetett be. (Megjegyzés: az OLEDB elnevezés régebbi mint az OLEDB-alapú adatelérés. Eredetileg az OLE betűk az „Object Link Embedding” kifejezést, a DB betűk a „Database” kifejezést jelentették, de ma már a Microsoft nem ezeket a fogalmakat kapcsolja az OLEDB-hez.) Az OLEDB-alapú adatelérés egy COM interfészre támaszkodik a legkülönbözőbb, nem feltétlenül relációs adatok elérésére. Ezért, az ODBC-alapú adateléréssel szemben, mely platformfüggetlen, az OLEDB-alapú adatelérés csak COM támogatást élvező platformokon használható. Lényege egy OLEDB adatszolgáltató, amint azt a 8.3. ábrán láthatjuk. Mivelhogy létezik egy OLEDB adatszolgáltató az ODBC részére is, az OLEDB-alapú adatelérés támogatja az ODBC meghajtókat is.
A fenti elméleti fejtegetéseket összefoglalva elmondhatjuk, hogy három lehetőségünk van kliensalkalmazásból relációs adatokat elérni és kezelni:
