3. diel - Prístupy pre prácu s relačnými databázami v .NET

V minulej lekcii, Vytvorenie lokálnej databázy vo Visual Studio , sme si pripravili databázu slovíčok.

V minulej lekcii, Vytvorenie lokálnej databázy vo Visual Studio , sme si pripravili databázu slovíčok. Dnešná tutoriál bude teoretický, uvedieme si problémy relačného a objektového sveta a ďalej prístupy, akými môžeme s databázou v C# .NET pracovať.

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

Objektový svet a svet relačných databáz (svet relačná) sú veľmi rozdielne. Jedná sa o 2 odlišné filozofie, o ktorých si tu trúfam vyhlásiť, že sú nezlučiteľné.

Relačné databázy sú overený spôsob ako pracovať s dátami. I keď existujú aj databázy plne objektovej, firmám sa do nich teraz neoplatí investovať peniaze a preto sa zatiaľ nepresadili. Po revolúcii v programovaní a príchode objektov samozrejme nastal problém s ukladaním dát, keďže relačné databázy objektovo nefungujú a objekty ukladať nevie. Existuje niekoľko možností, ako sa s týmto vysporiadať.

1. neobjektové programovanie

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

2. Databázový Wrapper

Prístup tzv. Wrapper nám umožňuje s databázou pracovať ako s objektom, však 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. Možno aj čiastočne mapovať dáta na existujúce triedy, však plnohodnotného konceptu objektového modelu nedosiahneme.

3. Objektovo relačné mapovanie

Objektovo relačné mapovanie (ORM) ide ortodoxne za myšlienkou OOP. Z databázy teda miesto pole hodnôt dostávame rovno objekty a tie na sebe majú 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čné databáz. Znie to skvele, že?

Háčik je samozrejme 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). C# má našťastie perfektne odladené ORM priamo v sebe, čiže nemusíme nič riešiť. Naopak napr. Sprevádzkovať ORM v PHP nie je nič jednoduché a tam preferujem prístup wrapper.

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ívna a je nutné pomýšľať na jeho konečnú podobu, odtienenie teda nie je úplné. Osobne mám k ORM neutrálny postoj a ak mi niekto spolu s jazykom poskytne štandardizované a odladené ORM, rád ho použijem. Ak nie, zaobídem sa bez neho.

4. Objektové databázy

Okrem databáz relačných existujú aj už spomínané databázy objektové. Tie rieši problém nezlučiteľnosti objektového a relačného prístupu. Poskytujú rovnaký komfort, ako ORM, ale vnútorne netreba 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čnej. 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ť. Nebudem je detailne popisovať, iba si ku každej možnosti krátko niečo povedzme. Je dôležité, aby ste vedeli, že existujú. Databázy sú veľmi rozsiahle tému, keď danú možnosť budete potrebovať, zistíte si o ňu viac.

Pripojená aplikácie

Prístup pripojené 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áciu som znázornil na obrázku:

Odpojená aplikácie - DataSet

Prístup odpojené aplikácia funguje tak, že máme v operačnej pamäti tzv. DataSet, ktorý v sebe obsahuje dáta z databázy. Aplikácia pracuje s DataSetem a občas sa DataSet 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 komponenta ADO.NET, ktorá je súčasťou .NET frameworku.

DataSet v sebe obsahuje tabuľky, tabuľka riadky a riadok stĺpce. 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 DataAdapter, pomocou ktorého si naplníme DataSet dátami. Príkazy už musíme písať v jazyku SQL danej databázy.

Máme teda určitú objektovú abstrakcii, 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 bol napr. List objektov a vôbec neriešime SQL dotazy, 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ýto luxus je horšie optimalizácia dotazov, ktorá ale väčšinou nevadí.

V našej aplikácii figuruje tzv. 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 DataClasses, tá potom na pozadí pomocou LINQ to SQL komunikuje s databázou a vykonáva za nás SQL dotazy. My s jazykom SQL vôbec neprídeme do styku as databáz pracujeme ako s objektovú štruktúrou v operačnej pamäti.

Dôkladný opis tejto technológie si necháme na nabudúce, rovnako ako vytvorenie prvý databázové aplikácie.

Entity Framework

Entity framework ide ešte ďalej, než LINQ to SQL. Jedná sa o konkurenčný a pokročilejšie technológiu k LINQ to SQL. Navyše vie napr. Väzbu M: N. Tento prístup sa najlepšie používa a ak nie ste 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, každý sa hodí k niečomu inému a do praxe by ste o nich mali mať prehľad. V budúcej lekcii, Pripojená databázová aplikácia v C # .NET , si predstavíme prístup pripojenej aplikácie.