4. diel - Prístupy pre prácu s relačnými databázami vo VB.NET

V minulej lekcii, Vytvorenie tabuľky v databáze vo Visual Studio vo VB.NET , sme si pripravili databázu slovíčok.

V dnešnom Databáze - ADO.NET tutoriále si popíšeme problémy relačného a objektového sveta a ďalej prístupy, akými môžeme s databázou v VB.NET pracovať.

Rozpor objektového a relačného prístupu

Objektový svet a svet relačných databáz je rozdielny. Sú to 2 odlišné filozofie, ktoré sú nezlučiteľné. Relačné databázy sú overený spôsob ako pracovať s dátami. Hoci existujú úplne objektové databázy, zatiaľ sa nepresadili. Relačné databázy objektovo nefungujú a nevedia ukladať objekty. Existuje niekoľko možností, ako sa s týmto vysporiadať.

Neobjektové programovanie

Prvou možnosťou je samozrejme programovať úplne bez objektov. Tým by sme však šli proti prúdu. Nemohli by sme používať žiadne komponenty tretích strán a náš kód by bol veľmi nekvalitný. Keďže VB.NET je objektový jazyk, ani by to v ňom dosť dobre nešlo.

Databázový Wrapper

Prístup tzv. wrappera nám umožňuje s databázou pracovať ako s objektom, ale komunikujeme s ňou stále v jej jazyku SQL. Miešame teda objektový a relačný kód. Prístup je akýmsi kompromisom a vyžaduje filozofiu OOP trochu ohnúť. Výhodou je zachovanie výkonu a schopností databázy za cenu miernej degradácie myšlienok OOP.

Dáta z databázy vidíme najčastejšie ako hodnoty v tabuľke (tá je objektom) a prichádzame o možnosť prideliť entitám nejakú funkcionalitu. Tú namiesto toho združujeme do tzv. manažérov. Je možné aj čiastočne mapovať dáta na existujúce triedy, avšak plnohodnotný koncept objektového modelu nedosiahneme.

Objektovo relačné mapovanie

Objektovo relačné mapovanie (ORM) ide ortodoxne za myšlienkou OOP. Z databázy teda namiesto poľa hodnôt dostávame rovno objekty, ktoré majú na sebe metódy. V jazyku SQL vôbec nekomunikujeme. Tabuľky v databáze vidíme ako kolekcia objektov, s ktorými môžeme pracovať bežnými prostriedkami jazyka. Sme vlastne úplne odtienení od toho, že pracujeme s relačnou databázou. Znie to skvele, že?

Háčik je v tom, že na pozadí dochádza k veľkej degradácii výkonu databázy, SQL dotazy sa generujú automaticky a sú často neefektívne. Ďalším problémom ORM je, že je veľmi zložité (nie na použitie, ale na naprogramovanie). VB.NET má našťastie perfektne odladené ORM priamo v sebe, čiže nemusíme nič riešiť.

Napr. sprevádzkovať ORM v PHP nie je nič jednoduché, a preto sa tam preferuje prístup wrappera.

Názory na ORM sú veľmi kontroverzné, napr. že samotná jeho myšlienka je nesprávna, pretože generovaný SQL kód skrátka nemôže byť efektívny a je nutné pomýšľať na jeho konečnú podobu. Odtienenie teda nie je úplné.

Objektovej databázy

Okrem databáz relačných existujú aj už spomínané databázy objektové. Tie riešia problém nezlučiteľnosti objektového a relačného prístupu. Poskytujú rovnaký komfort, ako ORM, ale vnútorne nie je potrebné dáta prevádzať do tabuliek, ukladajú sa rovno ako objekty.

Teoreticky neexistuje výkonnostný, ani iný dôvod, prečo by nemali nahradiť databázy relačné. V praxi sa ale bohužiaľ takmer nepoužívajú a môžeme len dúfať, že sa to časom zmení. Záujemcovia sa môžu pozrieť napr. na projekt MongoDB.

Možnosti pripojenia k databáze

V .NET máme niekoľko možností, ako databázu v našej aplikácii používať. Ku každej možnosti si niečo krátko povedzme.

Pripojená aplikácia

Prístup pripojenej aplikácie použijeme vo chvíli, keď potrebujeme dáta často v reálnom čase čítať alebo meniť. Pomocou tried DataReader, Command a Connection posielame databázu priamo príkazy v jazyku SQL a dostávame výsledky.

Situácia je znázornená na obrázku:

Odpojená aplikácia - DataSet

Prístup odpojenej aplikácie funguje tak, že máme v operačnej pamäti kolekciu objektov typu DataSet, ktorý v sebe obsahuje dáta z databázy. Aplikácia pracuje s kolekciou typu DataSet a občas sa táto kolekcia zosynchronizuje s ostrou databázou na serveri (disku). Za cenu menej aktuálnych dát získavame zvýšenie rýchlosti a pohodlnejšiu prácu. Tento prístup zhŕňa komponent ADO.NET, ktorý je súčasťou .NET frameworku.

Inštancia typu DataSet obsahuje v sebe tabuľky, tabuľka riadky a riadok stĺpca. Tabuľka je objekt. Môžeme do nej riadky pridávať a upravovať ich bez písania SQL kódu. Keď chceme spustiť na databázu nejaký príkaz, použijeme objekt typu DataAdapter, pomocou ktorého si naplníme inštanciu DataSet dátami. Príkazy už musíme písať v jazyku SQL danej databázy.

Situácia vyzerá nasledovne:

Máme teda určitú objektovú abstrakciu. S tabuľkami pracujeme objektovo, ale dáta sú stále len stĺpčeky v tabuľke, nie inštancie nejakých objektov. Tiež stále používame jazyk SQL. Z hľadiska vyššie uvedených prístupov sa jedná o wrapper.

LINQ To SQL

LINQ to SQL poskytuje kompletnú objektovú abstrakciu nad databázou (objektovo relačné mapovanie). S databázou pracujeme ako keby to bola napr. kolekcia objektov typu List. Vôbec neriešime SQL otázky, nevieme o tabuľkách ani stĺpcoch, všetko sa deje na pozadí automaticky. Otázka nám vracia rovno plnohodnotné objekty. Cena za taký luxus je horšia optimalizácia otázok, ktorá ale väčšinou nevadí.

V našej aplikácii figuruje objekt typu DataClasses, čo je objektová štruktúra databázy. Obsahuje triedy pre jednotlivé tabuľky. Stĺpce tabuľky sú vlastnosti daných tried. V aplikácii komunikujeme iba s týmto objektom. Ten komunikuje s databázou na pozadí pomocou LINQ to SQL a vykonáva za nás SQL otázky. My s jazykom SQL vôbec neprídeme do styku as databázou pracujeme ako s objektovou štruktúrou v operačnej pamäti.

Situáciu by sme znázornili takto:

Entity Framework

Entity framework ide ešte ďalej, než LINQ to SQL. Ide o konkurenčnú a pokročilejšiu technológiu k LINQ to SQL. Navyše vie napr. väzbu M:N. Tento prístup sa najlepšie používa a pokiaľ nie sme nejako limitovaní architektúrou danej aplikácie alebo výkonom, je dobrou voľbou pre väčšinu aplikácií.

V našom kurze si predstavíme postupne všetky prístupy.

V nasledujúcej lekcii, Pripojená databázová aplikácia vo VB.NET , sa pripojíme k databáze pomocou triedy SqlConnection a vytvoríme objekt typu SqlCommand, na ktorom zavoláme metódu ExecuteScalar(), aby sme zistili počet riadkov v databáze.