Rok Žontar ZAGOTAVLJANJE TRAJNOSTI OBJEKTOV V OGRODJU.NET Diplomsko delo Maribor, marec 2009
I Diplomsko delo univerzitetnega študijskega programa ZAGOTAVLJANJE TRAJNOSTI OBJEKTOV V OGRODJU.NET Študent: Študijski program: Smer: Mentor: Somentor: Rok Žontar UN ŠP Računalništvo in informatika Informatika dr. Marjan Heričko, red. prof. mag. Boštjan Kežmah Maribor, marec 2009
II UNIVERZA V MARIBORU (ime fakultete oz. visoke strokovne šole) Številka: Datum: SKLEP O DIPLOMSKEM DELU 1., študent-ka univerzitetnega (visokošolskega strokovnega) študija, izpolnjuje pogoje, zato se mu dovoljuje izdelati diplomsko delo. 2. Tema diplomskega dela je s področja katedre/oddelka/inštituta, pri predmetu. Mentor-ica: Somentor-ica: 3. Naslov diplomskega dela: 4. Vsebina diplomskega dela: 5. Diplomsko delo je potrebno izdelati skladno z»navodili za izdelavo diplomskega dela«in ga oddati v izvodih do v referatu za študentske zadeve. Predstojnik katedre/oddelka/inštituta: Mentor: Dekan-ica:
III ZAHVALA Zahvaljujem se mentorju dr. Marjanu Heričku za pomoč in vodenje pri opravljanju diplomskega dela. Prav tako se zahvaljujem somentorju mag. Boštjanu Kežmahu. Zahvaljujem se tudi sodelavcem v Laboratoriju za informacijske sisteme za nesebično pomoč. Posebna zahvala velja staršem, ki so mi omogočili študij in me ves čas podpirali.
IV ZAGOTAVLJANJE TRAJNOSTI OBJEKTOV V OGRODJU.NET Ključne besede: objektno-relacijska preslikava, domensko usmerjeno načrtovanje, LINQ to SQL, NHibernate, ADO.NET Entity Framework, ogrodje.net, primerjava UDK: 004.652.4/.5(043.2) Povzetek V diplomskem delu smo predstavili impedančno nesorazmerje med objektno orientiranimi programskimi jeziki in relacijskimi podatkovnimi bazami. Preučili in raziskali smo objektno-relacijske preslikovalnike in ugotovili na kak način pomagajo razvijalcem pri premostitvi teh nesorazmerij. Pri tem smo izpostavili vzorce, ki jih uporabljajo objektno-relacijski preslikovalniki, in neodvisnost ogrodja od izbranega ponudnika podatkovne baze. Opisali smo tri ogrodja za objektno-relacijsko preslikavo, ki temeljijo na ogrodju.net. Na tej podlagi smo določili primerjalne kriterije in izvedli primerjavo ter podali končno analizo.
V OBJECT PERSISTENCE IN THE.NET FRAMEWORK Key words: object-relational mapping, domain driven design, LINQ to SQL, NHibernate, ADO.NET Entity Framework,.NET framework, comparison UDK: 004.652.4/.5(043.2) Abstract In this diploma we have presented the impedance mismatch between object-oriented programming languages and relational databases. We researched and presented object-relational mapping and found out how this technology helps developers to overcome the impedance mismatch. The main focus was on object-relational patterns and persistence ignorance. We described three object-relational mapping frameworks which rely on the.net framework. On this base we defined some comparison criteria, performed the comparison and concluded with an analysis.
VI VSEBINA 1 UVOD... 1 2 OBJEKTNO-RELACIJSKI PRESLIKOVALNIKI... 2 2.1 TRAJNOST PODATKOV... 2 2.2 RAZLIKE MED RELACIJSKIM IN OBJEKTNO ORIENTIRANIM SVETOM... 4 2.3 OBJEKTNO RELACIJSKO PRESLIKOVANJE... 6 2.4 PODATKOVNI SLOJ... 8 2.5 DOMENSKO USMERJENO NAČRTOVANJE IN VZORCI ORM... 9 2.5.1 Vzorci domenske logike... 10 2.5.2 Vzorci dostopa do podatkov... 14 2.5.3 Objektno-relacijsko vedenjski vzorci... 16 2.5.4 Objektno-relacijski strukturni vzorci... 19 2.5.5 Objektno-relacijski vzorci za preslikovanje z uporabo meta podatkov... 22 2.6 NEODVISNOST MODELA OD OGRODJA... 24 2.6.1 Princip POCO... 24 2.6.2 Kriteriji»Persistence Ignorance«... 25 2.6.3 PI ali ne PI?... 27 3 OGRODJA ORM... 28 3.1 OGRODJE LINQ TO SQL... 28 3.1.1 Dodatki v C# 3.0... 28 3.1.2 Arhitektura ogrodja LINQ... 31 3.1.3 Preslikava... 35 3.1.4 Posodabljanje, vstavljanje in brisanje... 37 3.2 OGRODJE NHIBERNATE... 37 3.2.1 Iz Jave na.net... 37 3.2.2 Povpraševanja... 40 3.2.3 Posodabljanje, vstavljanje in brisanje... 42 3.3 OGRODJE ADO.NET ENTITY FRAMEWORK... 43 3.3.1 Arhitektura ogrodja ADO.NET Entity Framework... 43 3.3.2 Entitetni podatkovni model... 46
VII 3.3.3 Poizvedbe... 53 3.3.4 Posodabljanje, vstavljanje in brisanje... 56 4 PRIMERJAVA OGRODIJ... 58 4.1 KLASIFIKACIJA PRIMERJALNIH KRITERIJEV... 58 4.1.1 Grafična in pomožna orodja... 58 4.1.2 Podpora dedovanju in polimorfizmu... 58 4.1.3 Podpora različnim sistemom za upravljanje s podatkovno bazo... 59 4.1.4 Kriteriji»Persistence Ignorance«... 59 4.1.5 Dinamične poizvedbe... 60 4.1.6 Sprotno nalaganje in nalaganje na zahtevo... 60 4.1.7 Shranjene procedure... 61 4.1.8 Transakcije... 61 4.1.9 Predpomnjenje... 62 4.1.10 Zaklepanje... 62 4.1.11 Metrike programske kode... 63 4.1.12 Učinkovitost delovanja... 65 4.2 ANALIZA... 65 4.2.1 Grafična in pomožna orodja... 65 4.2.2 Podpora dedovanju in polimorfizmu... 66 4.2.3 Podpora različnim sistemom za upravljanje s podatkovno bazo... 67 4.2.4 Kriteriji»Persistence Ignorance«... 67 4.2.5 Dinamične poizvedbe... 69 4.2.6 Sprotno nalaganje in nalaganje na zahtevo... 70 4.2.7 Shranjene procedure... 70 4.2.8 Transakcije... 71 4.2.9 Predpomnjenje... 71 4.2.10 Zaklepanje... 72 4.2.11 Metrike programske kode... 73 4.2.12 Učinkovitost delovanja... 74 4.3 POVZETEK... 80 5 SKLEP... 83
6 LITERATURA IN VIRI... 85 VIII
IX SEZNAM SLIK Slika 2.1 Shematski prikaz ORM... 7 Slika 2.2 Trinivojska arhitektura [8]... 9 Slika 2.3 Domenski model [10]... 11 Slika 2.4 Modul tabele [10]... 13 Slika 2.5 Aktiven zapis [9]... 14 Slika 2.6 Preslikovalnik podatkov [10]... 15 Slika 2.7 Diagram zaporedja za vzorec enota dela [10]... 17 Slika 2.8 Diagram zaporedja za vzorec slovar identitet [10]... 18 Slika 2.9 Prikaz nalaganja na zahtevo [10]... 18 Slika 2.10 Preslikava asociacije ena-mnogo [10]... 20 Slika 2.11 Preslikovanje asociacije mnogo-mnogo [10]... 20 Slika 2.12 Ena tabela za vse razrede [12]... 21 Slika 2.13 Tabela na konkreten razred [12]... 21 Slika 2.14 Tabela na razred [12]... 22 Slika 2.15 Preslikovanje z uporabo meta podatkov [10]... 22 Slika 2.16 Zgradba povpraševalnega objekta [10]... 23 Slika 3.1 Arhitektura ogrodja LINQ [17]... 32 Slika 3.2 Grafično orodje za načrtovanje LINQ to SQL entitet znotraj Visual Studia 2008... 35 Slika 3.3 Arhitektura ogrodja NHibernate [24]... 38 Slika 3.4 Arhitektura ogrodja ADO.NET Entity Framework... 44 Slika 3.5 Grafično orodje za načrtovanje entitetnega podatkovnega modela... 47 Slika 3.6 Struktura meta podatkov... 48 Slika 4.1 Primerjava hitrosti izvedbe povpraševanja... 77 Slika 4.2 Povprečen čas izvedbe vnosa, posodobitve in izbrisa... 79
X SEZNAM PRIMEROV Primer 2.1 Navigacija v C# in SQL... 5 Primer 2.2 Dostop do podatkov v ADO.NET z uporabo razreda DataReader... 6 Primer 2.3 Dedovanje od specifičnega nadrazreda... 25 Primer 2.4 Izdelava objekta s tovarniško metodo... 26 Primer 3.1 Sklepanje o tipu spremenljivke... 28 Primer 3.2 Inicializacija objektov in zbirk... 29 Primer 3.3 Lambda izraz... 30 Primer 3.4 Razširljiva metoda... 30 Primer 3.5 Razširljive proti statičnim metodam... 31 Primer 3.6 Anonimni tip... 31 Primer 3.7 Povpraševalni izraz... 34 Primer 3.8 Generiran razred... 36 Primer 3.9 Dodajanje in odstranjevanje zapisov z uporabo LINQ to SQL... 37 Primer 3.10 Opis preslikave v datoteki hbm... 39 Primer 3.11 Povpraševanje z jezikom HQL... 41 Primer 3.12 Poizvedba z uporabo»query by criteria«... 42 Primer 3.13 Poizvedba z uporabo»query by example«... 42 Primer 3.14 Izsek iz CSDL sheme... 49 Primer 3.15 Izsek iz SSDL sheme... 50 Primer 3.16 Izsek iz MSL sheme... 51 Primer 3.17 Generirana koda iz EDM... 52 Primer 3.18 Poizvedba LINQ to Entities... 54 Primer 3.19 Poizvedba z uporabo Entity SQL in objektnih storitev... 54 Primer 3.20 Poizvedba z uporabo Entity SQL in graditeljem poizvedb... 54 Primer 3.21 Poizvedba z uporabo Entity SQL in ponudnika podatkov na nivoju entitet 56 Primer 3.22 Posodabljanje, vstavljanje in brisanje v ogrodju ADO.NET Entity Framework... 57 Primer 4.1 Primer testa za meritev časovne učinkovitosti... 75
XI SEZNAM TABEL Tabela 3.1 Standardni povpraševalni operatorji [20]... 33 Tabela 3.2 Povpraševalni operatorji in pripadajoča C# sintaksa... 34 Tabela 3.3 Osnovni elementi preslikave in njihov pomen... 39 Tabela 4.1 Kriteriji»Persistence Ignorance«... 68 Tabela 4.2 Izračunane metrike programske kode... 73 Tabela 4.3 Primerjava hitrosti izvedbe povpraševanja... 76 Tabela 4.4 Primerjava hitrosti izvedbe kompleksnega povpraševanja... 77 Tabela 4.5 Primerjava hitrosti nalaganja na zahtevo... 78 Tabela 4.6 Učinkovitost izrabe procesorja in pomnilnika... 79 Tabela 4.7 Povzetek primerjalnih kriterijev... 80
XII UPORABLJENE KRATICE ORM - Object-Relational Mapping DDD - Domain Driven Design ER - Entity-Relationship XML - Extensible Markup Language CLR - Common Language Runtime ADO - ActiveX Data Object SQL - Structured Query Language LINQ - Language Integrated Query HBM - Hibernate Mapping HQL - Hibernate Query Language CQ - Criteria Queries LOC - Lines of Code UML - Unified Modeling Language GoF - Gang of Four POCO - Plain old CLR Object POJO - Plain old Java Object EJB - Entity Java Bean PI - Persistence Ignorance GUID - Global Unique Identifier API - Application Programming Interface LTS - LINQ to SQL CSDL - Conceptual Schema Definition Language SSDL - Storage Schema Definition Language MSL - Mapping Specification Language SUPB - Sistem za upravljanje s podatkovno bazo ESQL - Entity SQL EC - Entity Client
Zagotavljanje trajnosti objektov v ogrodju.net Stran 1 1 UVOD Danes si ne moremo predstavljati informacijskih sistemov, ki ne bi bili odvisni od podatkov. V nekaterih primerih so podatki samo začasni in niso shranjeni v podatkovnih bazah, večinoma pa so hranjeni v relacijskih podatkovnih bazah. Za dostop do podatkovne baze obstaja več bolj ali manj uveljavljenih vzorcev in dobrih praks, kako zgraditi robusten, nadgradljiv in preverjen arhitekturni sloj za dostop do podatkov. Eden od teh vzorcev so objektno-relacijski preslikovalniki. Cilj diplomske naloge je razložiti problematiko dostopa do podatkov, ki jih hranimo v relacijskih podatkovnih bazah, in prikazati, kako ta problem naslavljajo objektno-relacijski preslikovalniki. V nadaljevanju diplomske naloge bomo predstavili strukturo OR-preslikovalnikov, pogoste vzorce, ki so uporabljeni pri implementaciji le-teh, in jih umestili v standardno tronivojsko arhitekturo informacijskih sistemov. Poleg tega bomo predstavili domensko usmerjeno načrtovanje in ugotovili, kako OR-preslikovalniki omogočajo tak način razvoja informacijskih sistemov. Po uvodu v teorijo OR-preslikovalnikov bomo predstavili tri ogrodja na programskem ogrodju.net, ki omogočajo objektno relacijsko preslikavo. Izbrali smo tri ogrodja za katera menimo, da so trenutno na tržišču najbolj zrela. Ta tri ogrodja sestavljajo Microsoftov LINQ to SQL, odprtokodni NHibernate in še eno Microsoftovo ogrodje ADO.NET Entity Framework. V tretjem poglavju bomo podrobneje opisali vsako od teh ogrodij in izpostavili njihove pozitivne in negativne lastnosti. Podrobneje si bomo pogledali nekatere novosti, ki so prišle z ogrodjem.net različice 3.5, in kako te pomagajo izdelati boljša povpraševanja. V praktičnem delu smo si zastavili cilj klasificirati kriterije na podlagi katerih bomo izvedli primerjavo. Pri tem se ne bomo omejili samo na kvantitativne kazalnike, ampak bomo upoštevali predvsem kvalitativne lastnosti primerjanih ogrodij. Ti kazalniki bodo služili kot osnova za primerjavo, ki jo bomo izvedli za zaključek praktičnega dela diplomske naloge.
Zagotavljanje trajnosti objektov v ogrodju.net Stran 2 2 OBJEKTNO-RELACIJSKI PRESLIKOVALNIKI 2.1 Trajnost podatkov Poenostavljeno lahko trajnost opišemo kot lastnost, da podatki»preživijo«izvajanje aplikacije, ki jih je ustvarila.[1] To je lahko urejevalnik besedil, ki shrani vsebino na trdi disk, in omogoča kasnejše uporabo in spreminjanje. V svetu informacijskih sistemov govorimo o trajnosti podatkov oz. objektov (angl.»object persistence«). Zmožnost hrambe in kasnejšega pridobivanja objektov je ključnega pomena za delovanje sodobnih informacijskih sistemov. Na voljo imamo različne načine, kako in kje hraniti podatke, izpostavili bomo le štiri najpogostejše: [2] pomnilnik, datotečni sistem, objektna podatkovna baza in relacijska podatkovna baza. Pomnilnik Hramba podatkov v pomnilniku mogoče ni tako nesmiselna, kot bi ocenili na prvi pogled. V primeru, da imamo mali podatkovni model, je prednost hrambe podatkov v pomnilniku, da ne potrebujemo orodij za preslikavo objektov v karkoli drugega, kajti že sami objekti in relacije med njimi so shranjeni v pomnilniku. Ne glede na to, kaj hranimo v pomnilniku, vedno obstaja nevarnost prekoračitve velikosti pomnilnika. V večjem podatkovnem modelu in veliki količini podatkov lahko dokaj hitro pride do občutne upočasnitve sistema, ko podatki prekoračijo predvideno velikost. Drugi problem predstavlja izguba podatkov ob izpadu sistema. Načini, kako preprečiti izgubo podatkov, so različni. Lahko zapisujemo vsako spremembo na objektu v dnevnik sprememb in ob ponovni vzpostavitvi sistema preberemo dnevnik, da vzpostavimo prejšnje stanje. To pa je zamudno opravilo in porabi veliko časa in sistemskih virov. Drugi način, kako se obvarujemo pred izgubo, je, da aplikacija v rednih intervalih izdela posnetek
Zagotavljanje trajnosti objektov v ogrodju.net Stran 3 podatkov in jih zapiše na datotečni sistem. Ob ponovnem zagonu se naloži zadnji posnetek, ob tem pa tvegamo izgubo podatkov, ki so nastali med zadnjim posnetkom in izpadom sistema. Največji problem predstavlja nezmožnost spreminjanja objektnega podatkovnega modela, kajti za spremembo strukture objekta je potrebno shraniti podatke, odstraniti aplikacijo iz pomnilnika, prevesti izvorno kodo in vzpostaviti prejšnje stanje, pri tem pa upoštevati spremembe, ki so bile narejene. Datotečni sistem Datotečni sistem je dobra izbira za hrambo podatkov, če želimo imeti prenosnost podatkov. Objekte lahko serializiramo v binarni obliki ali z uporabo označevalnega jezika XML (angl.»extensible Markup Language«) in jih prenašamo med različnimi sistemi ali aplikacijami. Serializacija je ena lažje izvedljivih načinov trajne hrambe podatkov, ker razredov ni potrebno prilagajati za namen hrambe. Pri serializaciji se binarni objekt pretvori v strukturiran niz znakov in zapiše v datoteko, od koder ga lahko rekonstruiramo oz. deserializiramo. XML-serializacija je posebna vrsta serializacije, ki zapiše objekt ali drevo objektov v dokument XML. Takšen način se je uveljavil predvsem pri delitvi podatkov preko spleta. Serializirani objekti vsebujejo le vrednosti atributov, ne pa tudi izvedljive kode metod. Tudi tukaj se srečamo s podobnimi problemi, kot pri rešitvi z uporabo pomnilnika, z izjemo velikosti. Trdi diski, CD- ali DVD-ploščki imajo mnogokrat večjo kapaciteto kot pomnilnik, zato omogočajo hrambo večje količine podatkov. Objektne podatkovne baze Objektne podatkovne baze so poizkušale olajšati zagotavljanje trajnosti objektov s tem, da so se izognile preslikavi objektov v neki drug format za hrambo. V objektni podatkovni bazi so shranjeni objekti, ki jih zna podatkovna baza prikazati kot objekte specifičnega objektno orientiranega programskega jezika. [3] Čeprav objektne podatkovne baze zmanjšujejo razmak med objektno orientiranimi programskimi jeziki in načinom hrambe, so vendar zaradi pomanjkanja standardov,
Zagotavljanje trajnosti objektov v ogrodju.net Stran 4 povpraševalnih jezikov, integracije in zrelosti ter razširjenosti relacijskih podatkovnih baz še vedno nišni proizvod. Relacijske podatkovne baze Že v uvodu smo omenili, da so kot rešitev za trajno hrambo podatkov danes najbolj razširjene relacijske baze. Razlogi za to so najverjetneje v uveljavljenosti, zaupanju in velikem tržišču, ki ga zasedajo te podatkovne baze. V relacijskih bazah so podatki shranjeni v tabelarični obliki, relacije pa so prikazane kot par primarnega in tujega ključa. [4] Tak način je preverjeno enostaven in dovolj učinkovit za potrebe večine aplikacij. Relacijske podatkovne baze ponujajo vse prednosti, ki jih prejšnje rešitve niso imele. Imajo visok nivo standardizacije, dodelan način povpraševanja z uporabo strukturiranega povpraševalnega jezika (angl.»structured Query Language«ali SQL), podporo transakcijam, možnost hkratnega dostopa do podatkov in še bi lahko naštevali. 2.2 Razlike med relacijskim in objektno orientiranim svetom V prejšnjem poglavju smo ugotovili, da so, kot način trajne hrambe podatkov, še vedno najbolj razširjene relacijske podatkovne baze. Vendar se pri razvoju informacijskih sistemov hitro srečamo z razlikami med objektno orientiranimi programskimi jeziki in relacijsko bazo, kar v literaturi zasledimo pod pojmom objektno-relacijsko impedančno nesorazmerje (angl.»object-relational Impedance mismatch«).[5] [12] Najprej bi izpostavili podatkovne tipe. Podatkovni tipi v ogrodju.net imajo svoje predstavnike v relacijskih bazah, vendar tukaj velikokrat pride do razlik. Za primer naj navedemo niz znakov, ki je v ogrodju.net predstavljen kot System.String. V relacijskih bazah je niz znakov implementiran na različne načine, kot so char, nchar, nvarchar ali text, katerim pa, razen v primeru text, moramo podati še dolžino. Drug tak primer je podatkovni tip za datum in čas System.DateTime, ki ima v relacijskih bazah več tipov, npr. date, time, datetime.
Zagotavljanje trajnosti objektov v ogrodju.net Stran 5 Podatkovni tipi v relacijskih bazah so lahko obvezni ali neobvezni. To pomeni, da lahko vstavimo vrednost ali null. Na drugi strani so v ogrodju.net primitivni tipi vrednostni, kar pomeni, da dobijo privzeto vrednost že ob deklaraciji. To pomanjkljivost so razvijalci odpravili z izidom ogrodja.net 2.0, kjer so dodali podporo za neobvezne tipe v programski jezik. Tako lahko uporabimo rezerviran znak? pred deklaracijo spremenljivke in s tem povemo prevajalniku, da tip lahko vsebuje null. Vendar to kasneje zahteva, da pred uporabo spremenljivke preverjamo, ali ima vrednost.[6] Do sedaj opisane razlike so vedno prisotne pri povezovanju z relacijsko podatkovno bazo, ne glede na proizvajalca ali izbrano ogrodje. Še večja razlika se pojavi že pri uporabi osnovnih konceptov objektno orientiranega razvoja. Kot smo opisali že v prejšnjem poglavju, so relacijske podatkovne baze organizirane v tabele. Relacije med njimi so implementirane s parom podvojenih ključev, primarnega in tujega. Podrejeni zapisi imajo, kot tuj ključ, zapisan primarni ključ glavnega zapisa, in tako»kažejo«na njim nadrejen zapis. V programskem jeziku imamo objekte, ki imajo relacije do drugih objektov, to pa je doseženo tako, da ima objekt referenco na vse z njim povezane objekte. Prav tako je razlika v navigaciji. Medtem ko so v relacijskem modelu vse povezave dvosmerne (za vsak podrejen zapis lahko pridobimo glavnega in obratno), lahko v objektnem modelu sami določimo tip relacije. Relacije so privzeto enosmerne, lahko pa dodamo povratno referenco in tako dobimo dvosmerno relacijo. Primer 2.1 prikazuje različno navigacijo v programskem jeziku C# in relacijsko povpraševalnem jeziku SQL. C#: narocilo.narocnik.naziv SQL: SELECT Naziv FROM Narocniki WHERE NarocnikId = ( SELECT NarocnikId FROM Narocila WHERE NarociloId = @narociloid) Primer 2.1 Navigacija v C# in SQL Nazadnje moramo omeniti še dedovanje kot enega od osnovnih konceptov OO-razvoja. Relacijske podatkovne baze ne podpirajo dedovanja v takšnem pomenu, kot ga poznamo iz
Zagotavljanje trajnosti objektov v ogrodju.net Stran 6 programskih jezikov, obstajajo pa vzorci, kako to razreševati. Te vzorce bomo opisali v kasnejšem poglavju. Kot smo spoznali, obstaja velika razlika med objektnim in relacijskim svetom. Zaradi tega so bili razvijalci prisiljeni v objektne modele vnašati specifike relacijskih podatkovnih baz in obratno. Tipičen primer tega so relacije mnogo-mnogo in dedovanje. Tako je trpel ali podatkovni ali razredni model informacijskega sistema. 2.3 Objektno relacijsko preslikovanje Običajno se v arhitekturi informacijskih sistemov zgradi poseben nivo, ki je zadolžen za komunikacijo z viri podatkov in pretvarjanjem surovih podatkov v objekte. V ogrodju.net se ta nivo najpogosteje gradi s pomočjo programskega modela ADO.NET. Modelno ogrodje ADO.NET ali»activex Data Objects za ogrodje.net«je osnovni način dostopa do podatkov, vključuje vse potrebne razrede in knjižnice za povezavo s podatkovnim virom in pridobivanje ter manipulacijo podatkov.[7] Primer 2.2 prikazuje dostop do podatkov z uporabo razreda DataReader, ključnega dela ogrodja ADO.NET. SqlConnection c = new SqlConnection( ); c.open(); SqlCommand cmd = new SqlCommand( @"SELECT c.name, c.phone, c.dateofbirth FROM Customers c WHERE c.city = @p0" ); cmd.parameters.addwithvalue("@po", "London"); DataReader dr = c.execute(cmd); while (dr.read()) { string name = dr.getstring(0); string phone = dr.getstring(1); DateTime date = dr.getdatetime(2); } dr.close(); Primer 2.2 Dostop do podatkov v ADO.NET z uporabo razreda DataReader Pri tem načinu dostopa do podatkov morajo razvijalci slej ko prej zapisati SQL-stavek, ki dostopa do podatkov. Pri tem naletimo na težavo, saj so SQL-poizvedbe zapisane v nizu, kjer nimamo podpore prevajalnika. Tako ne moremo preveriti, ali atribut v tabeli zares
Zagotavljanje trajnosti objektov v ogrodju.net Stran 7 obstaja, kajti sintaktične napake se pojavijo komaj pri izvajanju kode, kar otežuje testiranje in odpravo napak. Nadaljnja težava so parametri, ki jih prejme SQL-poizvedba, saj ti niso strogo tipizirani. Lahko se zgodi, da razvijalec pozabi vpisati parameter, ali pa vpiše napačno ime. Tudi tukaj aplikacija proži napako šele v času izvajanja. Zadnji problem, ki ga vidimo pri tem pristopu, je podatkovni tip, ki ga vrača razred DataReader. Le-ta se mora namreč ujemati s podatkovnim tipom v tabeli in smo spet odvisni od natančnosti razvijalca, ali uporablja metodo, ki vrača ustrezen tip. Rešitev za te probleme ponujajo objektno relacijski preslikovalniki (angl.»object relational mapping«). Po definiciji so objektno relacijski preslikovalniki, ali ORM programska tehnika za avtomatsko preslikavo podatkov med relacijski podatkovnimi bazami in objekti, z uporabo meta podatkov, ki opisujejo povezavo med objekti in tabelami, kot prikazuje slika 2.1 Slika 2.1[8]. Ogrodja ORM transformirajo podatke iz ene oblike v drugo in obratno, pri tem avtomatsko izdelajo SQL na podlagi meta podatkov. Slika 2.1 Shematski prikaz ORM Ogrodje ORM je sestavljeno iz naslednjih komponent: [8] Knjižnice za izvajanje osnovnih operacij, kot so ustvari, preberi, uredi in briši. Jezika ali knjižnice za izvajanje povpraševanj. Vmesnika za urejanje meta podatkov. Načina, kako omogočiti različne načine optimizacije, kot so nalaganje na zahtevo, transakcije, Zakaj torej izbrati rešitev ORM? Razlogov je več, našteli bomo samo najpomembnejše: Produktivnost Ročno kodiranje dostopa do podatkovne baze je delovno intenzivno. V [8] avtorji navajajo, da je približno 30 % celotne kode potrebne samo za dostop do podatkov, ki so shranjeni v podatkovni bazi. Če ob tem upoštevamo, da so to ponavljajoči se vzorci SQL-poizvedb in
Zagotavljanje trajnosti objektov v ogrodju.net Stran 8 manipulacij, ter da je navadno pokritost tega dela kode s testi nizka, lahko predpostavimo, da bodo ogrodja ORM zmanjšala vnos napak in zvišala produktivnost. Vzdrževanje Sistem z manjšim številom vrstic kode ali LOC (angl.»line of Code«) je zagotovo lažje vzdrževati. Ogrodja ORM omogočajo osredotočenje razvijalcev in načrtovalcev na domeno in problem, ki ga rešujejo. Pri tem spodbujajo uporabo vzorcev, vse to pa pripelje do preglednejše kode, ki jo je lažje vzdrževati. Poleg tega so sistemi, ki uporabljajo vmesni sloj ORM, bolj neodvisni od sprememb na obeh slojih. Tako lahko normaliziramo podatkovno bazo in to ne vpliva na objektni model in obratno, spremembe na objektnem nivoju ne pomenijo takojšne spremembe podatkovnega modela. Potrebno je spremeniti le meta podatke, ki povedo, kako se objekti preslikajo v tabele. Hitrost Pogost pomislek pri odločitvi o uporabi ORM je hitrost. Seveda, ročno kodiran dostop do podatkovne baze je zagotovo hitrejši od preslikovalnika, vendar je to enako, kot bi rekli, da je program, napisan v zbirnem jeziku, hitrejši od programa, napisanega v C#. To je seveda res, ampak če pogledamo trud, ki je potreben za pisanje programov v zbirnem jeziku in višjem programskem jeziku, ugotovimo, da je prevelik za majhno razliko, ki jo pridobimo pri hitrosti. Enako velja za ogrodja ORM. Zagotovo ne bodo nikoli tako hitra, kot ročno kodiran dostop, a moramo upoštevati trud, ki ga prihranijo. V tem poglavju smo spoznali koncept objektno relacijskih preslikovalnikov, njihovo zgradbo in lastnosti. V naslednjem poglavju bomo predstavili, kako se ORM ogrodja vključujejo v trinivojsko arhitekturo informacijskih sistemov. 2.4 Podatkovni sloj Trinivojska arhitektura temelji na ločevanju informacijskih sistemov na nivoje. Ti nivoji so med seboj šibko sklopljeni, kar pomeni, da posamezen nivo komunicira le s spodaj ležečim nivojem, pri čemer je odvisen le od vmesnika. To zagotavlja šibko sklopljenost med nivoji,
Zagotavljanje trajnosti objektov v ogrodju.net Stran 9 kar pomeni, da sprememba programske kode enega nivoja ne zahteva sprememb v drugih nivojih. Nivoji, kot prikazuje slika 2.2, so tipično razdeljeni na: [8] Predstavitveni nivo vsebuje razrede za delo z uporabniškim vmesnikom. Nivo poslovne logike vključuje poslovna pravila in operacije nad poslovnimi entitetami. Podatkovni nivo je odgovoren za shranjevanje in pridobivanje podatkov iz ene ali več podatkovnih zbirk. Ta nivo vsebuje tudi model poslovnih entitet. Podatkovna zbirka obstaja zunaj informacijskega sistema. Če je to relacijska podatkovna baza, potem vsebuje relacijske tabele in shranjene procedure. Pomožni razredi vsaka aplikacija ima nabor pomožnih razredov, ki niso v nobenem horizontalnem nivoju, ampak so na voljo vsem nivojem. Sem na primer spadajo razredi za beleženje in izjeme. Predstavitveni nivo Nivo poslovne logike Pomožni razredi Podatkovni nivo Podatkovna baza Slika 2.2 Trinivojska arhitektura [8] Ogrodja ORM in z njimi povezan objektni model se uvrščajo v spodnji podatkovni nivo. 2.5 Domensko usmerjeno načrtovanje in vzorci ORM Govoriti o ORM, ne da bi omenili domensko usmerjeno načrtovanje (angl.»domain Driven Design«) ali DDD, je skorajda nemogoče, kajti ta dva pojma sta tesno povezana. Z uporabo ogrodij ORM preselimo velik del načrtovanja, ki je bil prej usmerjen v podatkovni model (entitetno-relacijski model), nazaj na domeno, ki jo z aplikacijo naslavljamo. Ni se
Zagotavljanje trajnosti objektov v ogrodju.net Stran 10 treba ubadati z vprašanji, kako bo normalizacija vplivala na razredni diagram ali kako bo nova relacija med objekti vplivala na entitetno-relacijski model. Domensko usmerjeno načrtovanje je zbirka konceptov in vzorcev, ki pomagajo strukturirati domenski model aplikacije, ki je jedro vsakega informacijskega sistema in predstavlja abstrakcijo poslovnega sveta s pripadajočimi pravili in omejitvami. [9] Fokus razvoja se tako preseli na domeno, ki jo z rešitvijo naslavljamo. To omogoča, da ustvarjamo fleksibilne, nadgradljive in kakovostne rešitve. Poleg tega dober model domene omogoča lažjo komunikacijo z naročnikom. Razvijalci se že od nekdaj poslužujejo diagramov in modelov za lažje razumevanje in komunikacijo z naročniki. Tako tudi DDD dopolnjuje že znane tehnike, kot so primeri uporabe v modelirnem jeziku UML (angl.»unified Modeling Language«). Razvijalci le redko poznajo poslovno področje tako natančno, da ne bi potrebovali nobenega modela, v večini primerov si šele pridobivajo potrebna znanja in pri tem so modeli nepogrešljivi. V nadaljevanju bomo predstavili nekaj vzorcev objektno-relacijskih preslikovalnikov, povzetih po [10] in [9]. Razdeljeni so v pet skupin, glede na njihovo področje uporabe. 2.5.1 Vzorci domenske logike Domenska logika je najpomembnejši del informacijskega sistema, kajti tam je zajeto poslovanje podjetja. V tem delu sta opisana vzorca za delo in organizacijo domenske logike. Domenski model Pri razvoju informacijskih sistemov se srečujemo s kompleksnostjo poslovnega področja, ki ga sistem naslavlja. Za abstrakcijo tega se uporablja vzorec domenski model, ki predstavlja objektni model. Ta vključuje tako vedenjske vzorce, kot tudi podatke s katerimi operira.
Zagotavljanje trajnosti objektov v ogrodju.net Stran 11 Pogodba PriznaniPrihodki(in datum) IzračunPremij() * 1 Proizvod IzračunPremij(in Pogodba) 1 Strategija Izračuna Strategija Celostnega Izračuna Slika 2.3 Domenski model [10] Če se pri razvoju odločimo za uporabo vzorca domenski model, to pomeni, da v arhitekturo informacijskega sistema vnesemo nov sloj objektov, ki posnemajo podatke in poslovna pravila, ki operirajo z njimi. Domenski model je večinoma zelo podoben podatkovnemu, a vseeno obstajajo poglavitne razlike. Domenski model namreč spoji podatke in procese, ima večvrednostne atribute, kompleksno mrežo povezav in uporablja dedovanje in polimorfizem. Ločimo dva tipa domenskih modelov. Enostavnega, ki je zelo podoben podatkovnemu modelu in večinoma vsebuje samo en objekt na tabelo, in bogatega, kjer se model močno razlikuje od podatkovnega. V takem modelu srečamo dedovanje, gosto prepletanje objektov, strategijo in druge vzorce iz kataloga Gang of Four. V prvem primeru se za dostop do baze uporablja vzorec aktiven zapis, medtem ko je v bogatem modelu treba uporabiti vzorec preslikovalnik, ki omogoča neodvisnost domenskega od podatkovnega modela. V domenskem modelu najdemo naslednje konstrukte: [9] entitete, vrednostne objekte, storitve, agregate,
Zagotavljanje trajnosti objektov v ogrodju.net Stran 12 tovarne in repozitorije. Entitete so osnovni gradniki domenskega modela in predstavljajo abstrakcijo predmetov v realnem svetu. Njihova glavna značilnost je identiteta, ki ločuje posamezne primerke med seboj, in ne vrednost atributov. Tako tudi v realnem življenju človeške identitete ne določajo ime, priimek in naslov, ampak nekaj več. Kljub enakemu poimenovanju besede entiteta v entitetno-relacijskem modelu, ta ne predstavlja enakega pojma. Kajti v ERmodelu je vsaka konceptualna predstavitev tabele entiteta. V domenskem modelu je entiteta lahko le abstrakcija neke stvari v realnem svetu. Pogosto želimo entitete podrobneje opisati, a ne želimo dodati neskončnega števila atributov v entiteto, kajti zaradi tega bi lahko postal model nepregleden. Rešitev za to so vrednostni objekti. To so objekti, ki so zelo podobni entitetam, vendar jim manjka poglavitna značilnost, to je identiteta. Ti objekti služijo za podrobnejši opis entitet in so brez njih neuporabni, saj jim komaj identiteta entitete da pomen. Tako si lahko predstavljamo entiteto vozilo v informacijskem sistemu proizvajalca avtomobilov in vrednostni objekt dodatna oprema. Dodatna oprema v tem primeru podrobneje opisuje vozilo, a brez vozila ostane popolnoma brez pomena. Storitve ali (angl.»services«) so objekti, ki ne hranijo stanja, a so vseeno nepogrešljivi v domenskem modelu, saj izvajajo neko aktivnost. To so po navadi statični objekti, katerih funkcionalnost ne sodi v entitete ali vrednostne objekte. Poleg navadnih povezav med objekti, ki jim pravimo asociacije, zasledimo v domenskem modelu tudi močnejše asociacije, to so agregacije. Agregacija pove, da en objekt pripada drugemu in le tako lahko tvorita celoto oz. agregat. Tako lahko za prejšnji primer vozila izpeljemo agregat vozilo, ki je sestavljeno iz motorja, menjalnika, podvozja in koles. Agregati so pogosto povezani s tovarnami, saj je izdelava agregatov lahko težavno. Tovarna ali tovarniška metoda (angl.»factory method«) je uveljavljen vzorec GoF, ki je namenjen izdelavi objektov oz. skupine objektov. Kadar želimo skriti kompleksnost izdelave objektov ali želimo manjšo sklopljenost med entitetami, uporabimo tovarno.
Zagotavljanje trajnosti objektov v ogrodju.net Stran 13 Repozitoriji so uveljavljen način, kako pridobivamo podatke iz podatkovnega vira. Služijo kot vmesni sloj do podatkovne baze. Če imamo domenski model, neodvisen od podatkovne baze, v njem zagotovo zasledimo veliko število repozitorijev, saj ti služijo kot enkapsulacija dostopa do podatkovnega vira. Repozitorij mora vključevati funkcionalnost za iskanje in rekonstrukcijo objektov iz podatkovnega vira ter popravljanje in brisanje podatkov v podatkovni vir. Modul tabele Pogodba IzračunPremij(in ID) Proizvod TipProizvoda(in ID) Izračun Vstavi(in ID, in Vsota, in datum) PriznaniPrihodki(in kontaktid, in datum) Slika 2.4 Modul tabele [10] Ena glavnih prednosti pri objektno orientiranih jezikih je, da združimo podatke in operacije, ki se izvajajo nad njimi. Problem pri domenskih modelih je vmesnik do relacijskih podatkovnih virov. Posledično je potrebno vložiti mnogo truda, da transformiramo podatke iz ene oblike v drugo. Zato vzorec modul tabele organizira domenska pravila z enim razredom na tabelo v podatkovni bazi. Tako ena instanca razreda vsebuje vse potrebne operacije, ki se bodo izvajale nad podatki. Poglavitna razlika med tem vzorcem in domenskim modelom je v tem, da če imamo več naročil, bomo v domenskem modelu imeli več objektov, kjer bo vsak predstavljal eno naročilo, medtem ko bomo imeli v modulu tabele samo en objekt, ki bo skrbel za vsa naročila. To ima za posledico, da moramo pri klicu metode podati neki argument, po navadi identifikator oz. primarni ključ tabele, ki enolično določa podatke, nad katerimi operiramo.
Zagotavljanje trajnosti objektov v ogrodju.net Stran 14 Modul tabele je preprostejši vzorec in ne omogoča uporabe vseh konceptov objektno orientiranega razvoja, zato če želimo reševati kompleksnost poslovnega področja z uporabo polimorfizma in dedovanja, ta vzorec ni primeren in se priporoča uporaba domenskega modela v kombinaciji z vzorcem aktiven zapis. Če delujemo večinoma nad tabelaričnimi podatki in imamo enostavno poslovno področje, se lahko poslužimo modula tabele. 2.5.2 Vzorci dostopa do podatkov V tem poglavju bomo opisali vzorca, kako dostopati do podatkovne baze. To sta aktiven zapis in preslikovalnik podatkov. Aktiven zapis Oseba Ime Priimek DatumRojstva Vstavi() Posodobi() Izbriši() SocialniPrispevek() DavčneDajatve() Slika 2.5 Aktiven zapis [9] Vzorec aktiven zapis (angl.»active Record«) je zelo podoben modulu tabele, le da to ni načrtovalski vzorec, ampak spada v kategorijo vzorcev za dostop do podatkov. Aktiven zapis združuje podatke, operacije poslovne logike in metode za nalaganje in shranjevanje podatkov iz podatkovnega vira. Funkcionalnosti, ki jih premore aktiven zapis, so: [10] Konstruiranje instanc objekta iz zapisa tabele; izdelava primerkov objekta za kasnejše vstavljanje v PB; statična iskalna metoda, ki združuje pogosto uporabljena povpraševanja in vrača primerke objektov; izvajanje osnovnih operacij nad podatkovno bazo, kot so vstavi, posodobi in izbriši; pridobi in nastavi vrednost atributov; implementacija dela poslovne logike.
Zagotavljanje trajnosti objektov v ogrodju.net Stran 15 Pri implementaciji tega vzorca je potrebno natančno ujemanje strukture razreda s strukturo relacijske tabele, tako naj ima vsak atribut v tabeli svoj par v atributu razreda. Tuji ključi so lahko predstavljeni kot podatek, lahko pa vračajo ustrezen aktiven zapis referencirane tabele, kot je opisano v vzorcu preslikovalnik asociacij. V tem vzorcu so razredi preprosti in ne skrivajo pogleda na podatkovno bazo, zato se tudi ne uporabljajo z drugimi objektno orientiranimi vzorci. Poleg tega tak pristop ne omogoča šibke sklopljenosti, saj je objektni model zelo odvisen od podatkovnega. Preslikovalnik podatkov Oseba Ime Priimek DatumRojstva SocialniPrispevek() DavčneDajatve() Oseba Preslikovalnik Vstavi() Posodobi() Izbriši() Slika 2.6 Preslikovalnik podatkov [10] Vzorec preslikovalnik je osrčje vsakega ORM, ne glede na to, katero ogrodje izberemo. Preslikovalnik ustvari vmesni sloj med objekti domenskega modela in podatkovno bazo ter ju tako naredi neodvisna drug od drugega. Z ločitvijo teh slojev dosežemo večjo neodvisnost in manjšo odvisnost od sprememb, na primer normalizacijo tabel v podatkovni bazi, uporabo zbirk ali dedovanja v programskem jeziku. Ločitev objektnega modela od podatkovnega vira je torej glavna naloga preslikovalnika, pri tem pa se pojavi kar nekaj težav. Preprosti preslikovalnik bi preslikal tabelo v ekvivalenten razred, vendar stvari pogosto niso tako enostavne. Preslikovalnik potrebuje vrsto strategij, kako preslikati razrede, ki se preslikajo v več tabel, ali razrede, ki uporabljajo dedovanje. Pri vstavljanju in posodabljanju podatkov mora preslikovalnik zaznati, kateri objekti so se spremenili in kateri so bili na novo izdelani, ter spremembe ustrezno izvesti nad podatkovnim virom. Pri tem lahko uporabi vzorec enota dela, ki je primeren za reševanje tega problema.
Zagotavljanje trajnosti objektov v ogrodju.net Stran 16 Preslikovalnik potrebuje dostop do podatkov v domenskih objektih. Pogosto to predstavlja težavo, kajti za to potrebujemo javno dostopne atribute, kar pa je v lahko v nasprotju s poslovno logiko. Preproste rešitve za ta problem ni, se pa pogosto rešuje z uporabo refleksije, a ta močno upočasni delovanje sistema. V glavnem poznamo dva načina, kako je implementiran preslikovalnik in shranjevanje podatkov o preslikavi. Enostavnejši način je, da v kodi zapišemo preslikavo. To zahteva, da imamo preslikovalnik za vsak domenski objekt. Tak preslikovalnik ima v kodi zapisane poizvedbe SQL, ki jih polni z ustreznimi podatki iz objekta. Alternativa je uporaba preslikovanja z uporabo meta podatkov, ki jih hranimo v razredu ali posebni datoteki. Ta vzorec, ki je podrobneje opisan kasneje, omogoča, da imamo samo en preslikovalnik za vse domenske objekte. 2.5.3 Objektno-relacijsko vedenjski vzorci Objektno-relacijski vedenjski vzorci opisujejo obnašanje ogrodij ORM in vsebujejo napotke, kako implementirati določeno funkcionalnost. Enota dela Pri delu s podatkovnim virom, kjer pridobivamo, spreminjamo, brišemo in dodajamo objekte, je pomembno, da sledimo spremembam in jih nato vse shranimo. Za to skrbi vzorec enota dela (angl.»unit of Work«). Seveda lahko prožimo spremembo na podatkovni bazi ob vsaki spremembi objekta, vendar tak način privede do velike količine dostopov do podatkovne baze, kar se izkaže kot zelo počasno. Poleg tega bi pri uporabi transakcij morali držati to odprto za daljši čas, kar bi pomenilo, da nekateri zapisi ostajajo zaklenjeni.
Zagotavljanje trajnosti objektov v ogrodju.net Stran 17 Odjemalec Podatkovna baza Enota dela new (ID) : Kupec select nastavi limit objekt spremenjen shrani vse update shrani Slika 2.7 Diagram zaporedja za vzorec enota dela [10] Enota dela beleži vse, kar delamo z objekti v okviru poslovne transakcije. Ko smo končali, ugotovi vse spremembe in jih posreduje podatkovni bazi. Slovar identitet Slovar identitet je pomemben vzorec, saj skrbi, da se objekt, ki predstavlja en zapis v podatkovni bazi, naloži samo enkrat. Vzrok za to je različno razumevanje identitete. V relacijskem svetu je identiteta zapisa določena s primarnim ključem, na drugi strani v objektnem svetu se objekti med seboj ločijo glede na pomnilniški naslov v pomnilniku. Če bi dopustili, da se objekt izdela več kot enkrat, bi prišlo do konceptualne napake, saj bi različna objekta predstavljala konceptualno enak zapis.
Zagotavljanje trajnosti objektov v ogrodju.net Stran 18 Iskalec Slovar identitet Podatkovna baza najdi(1) najdeno = vrni(1) [najdeno!= null] najdeno [najdeno == null] select where ID = 1 Slika 2.8 Diagram zaporedja za vzorec slovar identitet [10] Da bi zagotovili samo enkratno ustvarjanje objektov, uporabimo vzorec slovar identitet. Ta vzorec hrani referenco na vse objekte, ki jih je preslikovalnik prebral iz baze. Tako preslikovalnik najprej preveri slovar, ali že objekt obstaja, in takrat vrne referenco, če ne, poišče ustrezen zapis v bazi, izdela objekt in ga shrani v slovar. Nalaganje na zahtevo Pri nalaganju podatkov iz podatkovne baze v pomnilnik je včasih dobro, da naložimo objekte komaj, ko jih zares potrebujemo. Zgodi se lahko, da želimo operirati samo z nekaj objekti in ne s celotnim drevesom objektov. Tako zmanjšamo obremenjenost podatkovne baze in zagotovimo koristnejšo porabo pomnilnika. pridobi naročila : Kupec Podatkovna baza [naročina niso naložena] select naročila naročila Slika 2.9 Prikaz nalaganja na zahtevo [10]
Zagotavljanje trajnosti objektov v ogrodju.net Stran 19 Za implementacijo tega vzorca se lahko uporablja inicializacija na zahtevo. Pri tem načinu so privzeto vse reference nastavljene na null. Ko zahtevamo objekt, se preveri ali ima objekt vrednost, če ne, se naloži iz podatkovne baze. Tak pristop se zdi enostavnejši, vendar ima svoje pomanjkljivosti. Tako moramo enkapsulirati dostop do podatkov samo z metodami ali atributi tudi znotraj razreda, saj lahko samo tako naložimo potrebne objekte. Drug problem se pojavi, če je vrednosti null dovoljena ali celo predvidena. V tem primeru moramo uvesti posebno vrednost, ki predstavlja vrednost null. Druga rešitev, ki je morda bolj primerna, je uporaba vzorca namestnika iz kataloga Gang of Four. Namestnik je objekt, ki zgleda kot objekt, ki naj bi ga predstavljal, a ne vsebuje nič. Podatki se iz baze naložijo šele ob prvem proženju. [11] 2.5.4 Objektno-relacijski strukturni vzorci V tem predelu bomo opisali vzorce, kako se preslikajo določene strukture iz objektnega sveta v relacijskega. Preslikovanje asociacij Asociacije so osnovna značilnost objektnih jezikov. V splošnem poznamo tri vrste asociacij, ki jih ločimo glede na števnost. Tako lahko imamo asociacije ena proti ena, ena proti mnogo in mnogo proti mnogo. Le-te se dajo preprosto implementirati z uporabo referenc ali zbirk. V svetu relacijskih podatkov smo žal bolj omenjeni. Tu imamo samo povezavo primarnega in tujega ključa, ki predstavljata relacijo ena proti mnogo. Naloga vzorca preslikovanje asociacij je torej zagotoviti transparenten prenos relacij med tabelami v podatkovni bazi v ustrezne zbirke ali reference v razredih in obratno. Pri relaciji ena proti mnogo to naredimo z zamenjavo tujega ključa z referenco na objekt, ki mu ta ključ pripada, ali izdelamo zbirko podrejenih objektov, ki jih dobimo s povpraševanjem po tujem ključu.
Zagotavljanje trajnosti objektov v ogrodju.net Stran 20 Album Naslov : string 1 * Skladba Naslov : string Albumi PK ID Naslov Skladbe PK ID Naslov FK1 AlbumID Slika 2.10 Preslikava asociacije ena-mnogo [10] Večji problem se pojavlja pri relacijah mnogo proti mnogo, saj te v relacijski bazi ne moremo predstaviti tako enostavno. Zato moramo izdelati vmesno tabelo, ki vsebuje tuja ključa povezanih tabel. V tem primeru mora preslikovalnik poskrbeti, da se relacije med objekti ustrezno pretvorijo v zapise vmesne tabele. Pri tem ni treba, da ima vmesna tabela objektno predstavitev v pomnilniku. Zaposlen Področje * * Zaposleni PK ID ZaposlenPodročje PK,FK1 ZaposlenID PK,FK2 PodročjeID Področje PK ID Slika 2.11 Preslikovanje asociacije mnogo-mnogo [10] Preslikovanje generalizacije Dedovanje ali generalizacija je prvina objektno orientiranih programskih jezikov. Omogoča gradnjo hierarhije razredov, pri čemer podrejeni razredi podedujejo atribute in metode nadrazredov. To je učinkovit način zagotavljanja ponovne uporabe kode in nepogrešljiv v sodobnih informacijskih sistemih. Skozi zgodovino so se uveljavili trije načini, kako razreševati dedovanje v relacijskih bazah. Ti so: Ena tabela za vse razrede
Zagotavljanje trajnosti objektov v ogrodju.net Stran 21 Račun Račun Transakcijski račun Varčevalni račun Elektronski račun Slika 2.12 Ena tabela za vse razrede [12] Pri tej rešitvi imamo v podatkovni bazi samo eno tabelo za vse objekte iz hierarhije dedovanja. Ta tabela vsebuje atribute ob vseh razredov in še dodaten ločilni atribut. Ta atribut loči med različnimi tipi objektov, tako da se preslikovalnik na podlagi te vsebine odloči, kateri objekt izdela in s katerimi podatki ga napolni. Razlog za uporabo te rešitve v ogrodjih ORM je preprostost, kajti v tem primeru ne potrebujemo povezovanja tabel med seboj. Čeprav je ta rešitev najpogosteje uporabljena, ima vseeno svoje pomanjkljivosti. Kot prvo bi omenili hitro naraščanje števila atributov z večanjem števila razredov v strukturi. Poleg tega opazimo, da so vsa polja nadrazredov označena kot neobvezna. Tabela na konkreten razred Račun Varčevalni račun Elektronski račun Transakcijski račun Transakcijski račun Varčevalni račun Elektronski račun Slika 2.13 Tabela na konkreten razred [12] Ta način preslikovanja razredov v tabele je najpogosteje uporabljen pri ogrodjih ORM. Prednost te rešitve je predvsem preprostost implementacije, saj naredimo tabelo za vsak konkreten razred. V primerjavi s prejšnjo rešitvijo je ta manj občutljiva na spremembe. Na primer, če želimo dodati nov razred v hierarhijo, je potrebno izdelati novo tabelo.
Zagotavljanje trajnosti objektov v ogrodju.net Stran 22 Težava te rešitve je podvajanje podatkov in polimorfizem. Tako moramo podatke iz abstraktnega razreda prepisati v vsako konkretno tabelo. Še večji problem se pojavi pri relacijah, ki so vezane ne abstraktni razred, saj je lahko teh kar hitro nepregledno mnogo. Tabela na razred Račun Račun Transakcijski račun Elektronski račun Varčevalni račun Transakcijski račun Varčevalni račun Elektronski račun Slika 2.14 Tabela na razred [12] Kot je razvidno iz imena, je pristop tabela na razred zelo podoben prejšnjem pristopu, le da imamo za vsak razred v hierarhiji svojo tabelo. Podrazredi so z abstraktnim razredom povezani z relacijo. Ta pristop je dober, ker omogoča polimorfizem ter ne podvaja podatkov, je pa težji implementacijo v ogrodju ORM, saj zahteva večjo kompleksnost pri povpraševanju. 2.5.5 Objektno-relacijski vzorci za preslikovanje z uporabo meta podatkov Naslednji del opisuje OR-preslikovalnike, ki za preslikavo uporabljajo meta podatke. Ti podatki so lahko implementirani na različne načine, kot so dokumenti XML ali v obliki programske kode. Preslikovanje z uporabo meta podatkov Preslikava podatkov Ime razreda Ime tabele 1 * Preslikava atributov Ime atributa razreda Ime atributa tabele Slika 2.15 Preslikovanje z uporabo meta podatkov [10]
Zagotavljanje trajnosti objektov v ogrodju.net Stran 23 Večina kode v ORM ogrodjih skrbi za preslikavo atributov tabel v atribute objektov in obratno. Vzorec preslikovalnik z uporabo meta podatkov zmanjšuje obseg te kode, saj omogoča razvijalcu, da opiše preslikavo v obliki meta podatkov. Načina uporabe meta podatkov sta dva. Prvi uporablja generator kode, ki kot vhodni parameter prejme meta podatke in na njihovi podlagi generira kodo, ki izvaja preslikavo. To je preprostejši način, a pomeni, da je ob spremembi meta podatkov potrebno na novo generirati in prevesti vsaj del izvorne kode informacijskega sistema. Drug način je uporaba refleksije. Tak preslikovalnik prejme meta podatke, ki vsebujejo ime objekta in pripadajoče atribute ter njihovo preslikavo, in iz njih ustrezno napolni objekte s podatki. V tem primeru lahko polno izkoristimo funkcionalnosti, ki jih omogoča refleksija, žal pa se ne moremo izogniti njeni veliki časovni zahtevnosti. Nadaljnja prednost tega načina je, da lahko tak generični preslikovalnik uporabimo na več projektih, brez spremembe izvorne kode. Povpraševalni objekt : Povpraševanje 1 * * : Kriterij Operator = ">" Atribut = "Zaposleni" Vrednost = 0 : Kriterij Operator = "=" Atribut = "Priimek" Vrednost = "Novak" Slika 2.16 Zgradba povpraševalnega objekta [10] Povpraševanja so uveljavljen način, kako pridobimo podatke iz podatkovne baze. Iz relacijskih podatkovnih baz je poznan jezik SQL (angl.»structured Query Language«), ki je namenjen prav temu. Slabost tega jezika je, da operira nad relacijskimi tabelami, kar pomeni, da mora razvijalec poznati strukturo podatkovne baze. Zaradi tega želimo imeti možnost izvajanja povpraševanj na ravni objektov in prav to nudi vzorec povpraševalni objekt (angl.»query Object«).
Zagotavljanje trajnosti objektov v ogrodju.net Stran 24 Povpraševalni objekt je implementacija vzorca interpreter iz kataloga GoF, to je struktura objektov, ki se je zmožna preslikati v SQL-poizvedbo. Poizvedbo lahko naredimo z referenciranjem razredov in atributov, ne pa tabel in atributov. Na tak način zagotovimo neodvisnost povpraševanja od podatkovnega modela. 2.6 Neodvisnost modela od ogrodja 2.6.1 Princip POCO Zadnje poglavje tega dela bomo posvetili neodvisnosti domenskega modela od izbranega ogrodja za ORM. To je pomembno predvsem glede šibke sklopljenosti med posameznimi nivoji. Če želimo graditi informacijski sistem z uporabo domenskega modela in po načelih domensko usmerjenega načrtovanja, moramo odločitev o izbiri ogrodja preložiti čim bolj na konec. Tako lahko večino časa posvetimo razvoju in izboljšanju domenskega modela. Zaradi tega želimo tudi čim večjo neodvisnost modela od izbranega ogrodja ORM. Že iz javanskih časov je uveljavljen pojem POJO, kar je angleški akronim za»plain Old Java Object«in pomeni, da želimo imeti»čiste«objekte, brez dodatnih vmesnikov, atributov, anotacij ali metod, ki jih vsiljuje ogrodje. Ta termin je našel tudi svojo inačico v ogrodju.net, in sicer POCO. POCO pomeni»plain Old CRL Object«in ima enak pomen kot javanska sopomenka, samo da se nanaša na objekte ogrodja.net.[12] Zagovorniki pristopa POJO oziroma POCO poudarjajo, da želijo razvijati domenski model čisto neodvisno od katerega koli ogrodja. Le s tem bi lahko zagotovili kakovosten in nadgradljiv informacijski sistem, ki bi bil enostavnejši za vzdrževanje.[2] Z nadaljnjim razvojem ogrodij za objektno relacijsko preslikovanje se je pojavila potreba po novem pojmu, ki bi označeval neodvisnost modela od ogrodja. Razlog je tudi v tem, da termin POJO izvira še iz časov pred ORM in se je v preteklosti nanašal na neodvisnost objektov od poslovnih javanskih zrn ali EJB. Jimmy Nilsson v [2] navaja nov pojem, ki morda boljše opisuje neodvisnost komponent, to je»persistence Ignorance«(PI).»Persistence Ignorance«pomeni, da lahko uporabljamo navadne razrede, kjer se osredotočamo na domeno in probleme, ki jih rešujemo, in se ne ubadamo z vidiki, ki jih vsiljuje ogrodje. Lep primer, kako ugotovimo, ali smo dodali v projekt nezaželeno kodo,
Zagotavljanje trajnosti objektov v ogrodju.net Stran 25 je, da pogledamo reference projekta. Če knjižnico, je to lahko že kazalec, da smo dodali nezaželeno kodo. ugotovimo, da imamo referenco na drugo V nadaljevanju sledi sedem kriterijev, ki jih definira PI, ki jih ogrodje ne sme izpolnjevati, da domenski model postane neodvisen od ogrodja.[2] 2.6.2 Kriteriji»Persistence Ignorance«Dedovanje od specifičnega nadrazreda Pogosta praksa pri ogrodjih je, da morajo razredi dedovati od določenega nadrazreda, ki ga predpisuje ogrodje, zato da lahko uporabljamo funkcionalnost ogrodja. To je prikazano v primeru 2.3. public class Narocilo : PersistentObjectBase { } Primer 2.3 Dedovanje od specifičnega nadrazreda Na prvi pogled to mogoče ne zgleda tako slabo, vendar smo s tem, ko smo dedovali od razreda ogrodja, porabili edino možnost za dedovanje, kajti v ogrodju.net imamo samo enkratno dedovanje. Še večji problem je, če imamo že načrtovan domenski model z uporabo dedovanja in vzorcev GoF, kajti takega modela ni mogoče kar tako preslikati v podatkovno bazo. Poleg tega nadrazred vsebuje še dodatne javne metode, ki so potem vidne razvijalcu, ki uporablja konkretni razred, čeprav tja ne sodijo in lahko povzročijo zmedo. Izdelava primerkov objektov samo s tovarniško metodo Druga pogosta praksa je izdelava primerkov objektov s tovarniško metodo. Ogrodja to uporabljajo za sledenje spremembam na atributih. Tako namesto podanega razreda izdelajo primerek podrazreda, ki vključuje funkcionalnost sledenja in to skrijejo za tovarniško metodo.
Zagotavljanje trajnosti objektov v ogrodju.net Stran 26 Načrtovalci podpirajo uporabo vzorca tovarne v domenskih modelih, vendar je nesprejemljivo, da ogrodja predpisujejo uporabo tovarniških metod za izdelavo objektov, kot kaže primer 2.4. Narocilo n = (Narocilo) PersistentObjectFactory.CreateInstance( typeof(narocilo)); Primer 2.4 Izdelava objekta s tovarniško metodo Uporaba posebnih podatkovnih tipov, kot so zbirke Da bi orodja podpirala nalaganje na zahtevo, se velikokrat zahtevajo posebne oblike podatkovnih tipov. Primer tega so zbirke. Uporaba zbirk je zagotovo dobra praksa objektno orientiranega razvoja, vendar bi bilo boljše, če bi ogrodja podpirala privzete zbirke in ne predpisovale svojih. Tako le še znižujejo neodvisnost modela. Novi podatkovni tipi lahko prinesejo novo funkcionalnost. Nekatera ogrodja uporabljajo posebne podatkovne tipe, da sledijo spremembam, ki jih potrebuje vzorec enota dela. Tako se shranjujejo vse spremembe na drevesu objektov in se nato naenkrat shranijo v podatkovno bazo. Implementirati predpisan vmesnik To je podoben kriterij kot dedovanje od specifičnega nadrazreda, vendar tukaj ne rušimo verige dedovanja, ampak implementiramo samo vmesnik. V ogrodju.net ni omejitve, koliko vmesnikov lahko razred implementira, tako da ta kriterij ne predstavlja večje omejitve pri načrtovanju domenskega modela. Večjo težavo lahko imamo pri uporabi vmesnikov, če le-ti predpisuje metode, ki jih mora razred implementirati. Ogrodja predpisujejo vmesnike zaradi različnih razlogov. Nekatera jih imajo zaradi sledenja spremembam, druga pa izkoriščajo vmesnik kot zastavico, kateri objekti se hranijo. Predpisati specifičen konstruktor Še en način, kako ogrodja zagotavljajo dostop do podatkov, je predpisana uporaba specifičnega konstruktorja. Tak konstruktor ni v ničemer povezan z domenskim modelom in služi le ogrodju.
Zagotavljanje trajnosti objektov v ogrodju.net Stran 27 Predpisati obvezne specifične atribute Nekatere rešitve ORM zahtevajo, da vnesemo v domenski model specifične atribute, kot so na primer globalni enolični identifikatorji (Guid). Takšna rešitev je moteča in vnaša v razrede nepotrebno kodo. Prepovedana ali obvezna uporaba določenih konstruktov Kot pri primeru za uporabo tovarniške metode lahko ogrodje predpiše obvezno uporabo rezervirane besede virtual pri vseh atributih. Ta rezervirana beseda pomeni, da so lahko metode, atributi, indeksi in deklaracije dogodkov prepisane v dedovanih razredih. [13] Nasproten primer je rezervirana beseda readonly. Če uporabimo to rezervirano besedo na atributu, lahko vrednost tega nastavimo samo v konstruktorju.[14] Ogrodje lahko prepove uporabo te rezervirane besede, ker v nasprotnem primeru ni zmožno spreminjati atributa od zunaj. 2.6.3 PI ali ne PI? To so včasih le manjše nevšečnosti, ki v splošnem ne vplivajo na arhitekturo sistema. Tako se postavlja vprašanje:»pi ali ne PI?«. Črno-bele rešitve tukaj ni. Zagotovo 100 % neodvisnosti od izbranega ogrodja ne bomo nikoli dosegli, kajti vse, kar je ekstremno, vključuje visoke stroške. Vprašanje je samo, koliko načrtovalske svobode smo pripravljeni žrtvovati za določeno funkcionalnost. Poglejmo si primer: V ogrodjih ORM se pogosto pojavi odločitev, ali shraniti spremembe objekta na koncu nekega scenarija. Želeli bi, da se objekt shrani samo, če so bili spremenjeni njegovi atributi. Še več, želeli bi, da bi bil objekt sam zadolžen za to, da sporoči enoti dela, da se je atribut spremenil in se v bazi popravijo samo spremenjeni atributi. Ampak to zahteva kršitev pravil PI. Drug način je, da objekt ne signalizira nič, ampak si ogrodje zapomni, kakšno je stanje objekta, ko je bil pridobljen iz baze. Nato ob shranjevanju preveri razlike in po potrebi zapiše spremembe v bazo. Takšna rešitev zahteva več časa in sredstev, saj mora ogrodje z uporabo knjižnic iz imenskega področja System.Reflection preveriti vse atribute objekta za spremembe.[15]
Zagotavljanje trajnosti objektov v ogrodju.net Stran 28 3 OGRODJA ORM 3.1 Ogrodje LINQ to SQL Ogrodje LINQ to SQL je del tehnologije LINQ ali Language Integrated Query, kar v prevodu pomeni povpraševanja, vključena v programski jezik. LINQ ponuja nov pristop do podatkov, saj vpelje povpraševanja, kot jih poznamo iz jezikov SQL in XQuery, na nivo programskih jezikov. LINQ je del ogrodja.net 3.5 in ga sestavlja kombinacija knjižnic ali API (angl.»application Programming Interface«) ter razširitev programskih jezikov ogrodja.net. V nadaljevanju bomo predstavili nekatere novosti v programskem jeziku C# 3.0, ki omogočajo uporabo LINQ. 3.1.1 Dodatki v C# 3.0 Tehnologija LINQ, katere del je tudi ogrodje LINQ to SQL, je vnesla v programski jezik C# kar nekaj novosti. Zato je z ogrodjem.net verzije 3.5 izšla tudi posodobljena različica programskega jezika C#, ki so jo oštevilčili s 3.0. Seveda so za delo z LINQ morali dopolniti tudi prevajalnik. Pri tem je potrebno poudariti, da je izvajalno okolje ostalo enako in se nespremenjeno uporablja že od verzije 2.0. Sklepanje o tipu spremenljivke C# 3.0 ponuja novo ključno besedo, ki omogoča, da deklariramo lokalno spremenljivko, ne da bi pri tem eksplicitno določili njen tip. Tega prevajalnik avtomatsko določi ob prevajanju izvorne kode, tako da besedico var zamenja z ustreznim tipom, ki ga pridobi iz desne strani enačbe. Tako prevajalnik proizvede enako vmesno kodo, ne glede na to ali uporabimo var ali določimo konkreten tip. Primer 3.1 prikazuje različne možnosti uporabe nedoločene spremenljivke. var i = 12; var s = "Zdravo"; var d = 1.0; var oseba = new Oseba(); var seznamoseb = new List<Oseba>(); Primer 3.1 Sklepanje o tipu spremenljivke
Zagotavljanje trajnosti objektov v ogrodju.net Stran 29 Kljub temu da nismo konkretizirali tipa podatkovne spremenljivke, imamo polno podporo prevajalnika in IntelliSense v razvojnem okolju Visual Studio 2008. Prednost te novosti je predvsem pri uporabi tehnologije LINQ, kjer poizvedbe vračajo IEnumerable<T> ali IQuerable<T>, kar je za razvijalca nepregledno in zato rajši uporablja nedoločen tip var.[16] Drug zelo pogost način porabe je pri iteraciji skozi zbirko s stavkom foreach, kjer lahko uporabimo var namesto konkretnega tipa zbirke. Inicializacija objektov in zbirk Inicializacija objektov omogoča, da določimo vrednost enega ali več atributov v enem stavku. Do sedaj je bilo potrebno atribute inicializirati vsakega posebej v svoji vrstici. Nov način omogoča, da to opravimo na bolj pregleden in krajši način z uporabo inicializacijo objektov, kot prikazuje primer 3.2. var tocka = new Tocka { X = 1, Y = 2 }; var tocka2 = new Tocka("Druga tocka") { X = 7, Y = -3 }; var seznamoseb = new List<Oseba> { new Oseba { Ime = "Janez", LetoRojstva = 1965 } new Oseba { Ime = "Miha", LetoRojstva = 1973 } }; Primer 3.2 Inicializacija objektov in zbirk Nov način poznamo tudi za inicializacijo zbirk. Nova sintaksa omogoča inicializacijo zbirk, ki implementirajo vmesnik IEnumerable in ponujajo metodo Add. Tako lahko na krajši in bolj pregleden način izdelamo seznam oseb, ki že vsebuje nekatere podatke (primer 3.2). Potrebno je poudariti, da je tak način inicializacije le skrajšana in bolj pregledna oblika. Prevajalnik proizvede enako vmesno kodo, kot če bi najprej poklicali konstruktor in nato nastavili atribute v enakem vrstnem redu.[16] Razlog, da so uvedli ta dodaten način, je uporaba anonimnih tipov, ki jih bomo opisali kasneje. Lambda izrazi Lambda izrazi (angl.»lambda expressions«) so nadgradnja delegatov in anonimnih metod, ki jih poznamo že iz ogrodja.net verzije 2.0. Predstavljajo prenos značilnosti funkcijskih jezikov, kot je LISP, v objektno-orientirane, kot je C#, in temeljijo na lambda računu [16].
Zagotavljanje trajnosti objektov v ogrodju.net Stran 30 Delegati so poznani že od prve verzije ogrodja.net. Ti so bili nadgrajeni z anonimnimi metodami v verziji 2.0 in so omogočali zgoščen zapis delegata, ki ga ni bilo potrebno eksplicitno poimenovati. Vendar je še vedno bilo potrebno zapisati besedo delegate in parametre, ki jih metoda prejme. Lambda izrazi omogočajo še krajši zapis, saj izpustijo deklaracijo delegata in parametrov. Lambda izraz je sestavljen iz enega ali več parametrov, katerim sledita lambda operator (=>) in izraz. Primer 3.3 prikazuje lambda izraz in ekvivalentno predstavitev v C# 2.0. oseba => oseba.ime == "Janez"; Func<Oseba, Boolean>(oseba) { return oseba.ime == "Janez"; } Primer 3.3 Lambda izraz Razširljive metode Razširljive metode (angl.»extension methods«) omogočajo razvijalcem, da naknadno dodajo metode že definiranim razredom. [16] To so statične pomožne metode, ki jih po navadi definiramo v pomožnih razredih, a delujejo nad podatki določenega objekta. Razširljivo metodo definiramo kot statično metodo, ki ima kot prvi parameter tip, nad katerim izvajamo razširjeno metodo, in ključno besedo this. V primeru 3.4 vidimo razširljivo metodo, ki deluje nad vsemi objekti, ki implementirajo vmesnik IEnumerable<int> in mu doda metodo vsota, ki sešteje vsa števila v zbirki in vrne vsoto. Na koncu primera je prikazana uporaba te razširjene metode nad seznamom števil. static long Vsota(this IEnumerable<int> stevila) { long vsota = 0; foreach (var stevilo in stevila) vsota += stevilo; } return vsota; long vsota = new List<int> { 1, 2, 3, 4, 5, 6, 7, 8, 9 }.Vsota(); Primer 3.4 Razširljiva metoda Razširljive metode so ključni del tehnologije LINQ, saj implementirajo vse operacije, ki jih potrebujemo za izvajanje povpraševanj. To so Select, Join, OrderBy, GroupBy, Where
Zagotavljanje trajnosti objektov v ogrodju.net Stran 31 in podobne, ki so definirane nad vmesnikom IEnumerable<T>. Če bi razvijalci pri Microsoftu hoteli dopolniti vmesnik IEnumerable<T>, da bi vseboval vse potrebne metode, bi to potegnilo za sabo ogromno kode, saj bi bilo potrebno popraviti tudi vse razrede, ki implementirajo ta vmesnik. Pomožni razredi s statičnimi metodami tudi niso predstavljali rešitve, saj bi nepotrebno oteževali berljivost kode. Poleg tega razširljive metode omogočajo veriženje in zato lažjo berljivost, kot prikazuje primer 3.5. Prikazan razred Enumerable je del LINQ in se nahaja v imenskem prostoru System.Linq. int vsotalihih = stevila.select(stevilo => stevilo % 2 == 1).sum(); int vsotasodih = Enumerable.Sum( Enumerable.Select(stevila, stevilo => stevilo % 2 == 0)); Primer 3.5 Razširljive proti statičnim metodam Anonimni tipi Zadnja novost C# 3.0 so anonimni tipi. Ti omogočajo razvijalcu, da ustvari podatkovni tip, ne da bi za to moral izdelati nov razred. Sintaksa je podobna kot pri inicializaciji objektov, le da izpustimo ime razreda in zapišemo samo new. Pri tem je pomembno, da uporabimo var, kot tip na levi strani enačbe. V kombinaciji z LINQ lahko uporabimo anonimne tipe kot začasne objekte, v katerih shranimo rezultate poizvedb. var kontakt = new { Ime = "Janez", LetoRojstva = 1969 } Primer 3.6 Anonimni tip Čeprav sami nismo definirali razreda, se v ozadju izdela definicija razreda z ustreznimi atributi, ki smo jih definirali. Lahko imamo tudi več primerkov tega razreda, vendar moramo pri instanciranju paziti, da uporabimo enake atribute v enakem vrstnem redu, kajti samo tako bo lahko prevajalnik ugotovil, da gre za primerke enega razreda. 3.1.2 Arhitektura ogrodja LINQ Arhitektura tehnologije LINQ je ločena na 3 nivoje, kot prikazuje slika 3.1. Na najvišjem nivoju najdemo programske jezike, kot sta C# 3.0 in VB.NET 9.0, ki ponujata dodatke za uporabo z LINQ.
Zagotavljanje trajnosti objektov v ogrodju.net Stran 32 Na vmesnem nivoju najdemo knjižnice iz imenskega področja System.Linq, ki služijo za izvajanje poizvedb. Znotraj tega najdemo standardne povpraševalne operatorje, ki jih bomo podrobneje opisali kasneje. Slika 3.1 Arhitektura ogrodja LINQ [17] Tehnologija LINQ omogoča izvajanje povpraševanja nad različnimi podatkovnimi viri. Kot podatkovni vir lahko uporabimo objekte, datoteke XML ali ADO.NET vključene komponente, kot so DataSet-i, SQL podatkovne baze in entitete. LINQ to Objects predstavlja skupno osnovo za vse različice in služi za povpraševanja nad objekti, shranjenimi v pomnilniku. Operira lahko nad poljubno zbirko objektov, ki implementira vmesnik IEnumerable. Za datoteke XML je bil razvit LINQ to XML, ki ponuja razrede za delo z datotekami XML, kot so XDocument, XElement in XAttribute. Z uporabo LINQ lahko učinkovitejše pišemo poizvedbe nad strukturo dokumenta XML, kot sedaj z uporabo XPath. Največ pozornosti bomo posvetili različici LINQ to SQL, vendar moramo kljub temu še omeniti ostali dve različici, ki omogočata dostop do podatkov, shranjenih v relacijski podatkovni bazi. Prva je LINQ to Datasets, ki kot že ime pove, operira nad objekti tipa
Zagotavljanje trajnosti objektov v ogrodju.net Stran 33 DataSet. DataSeti so zelo razširjen način predstavitve relacijske tabele v pomnilniški strukturi. LINQ nad DataSeti operira enako kot nad zbirkami objektov, le da ne vrača objektov, ampak ustrezne zapise tabele. Druga možnost je uporaba LINQ to Entities, ki je namenjen povpraševanjem nad entitetami znotraj ogrodja ADO.NET Entity Framework, ki ga bomo podrobneje opisali v kasneje. Povpraševalni operatorji V prejšnjem poglavju smo opisali in prikazali uporabo razširljivih metod. LINQ izkorišča razširjene metode, ki so definirane v razredu System.Linq.Enumerable, za izvajanje povpraševanj. Tem metodam pravimo standardni povpraševalni operatorji in so našteti v tabeli 3.1. Tabela 3.1 Standardni povpraševalni operatorji [20] Skupina Izbira Omejitve Agregacije Pretvorbe Grupiranje Združevanje Razvrščanje Operacije nad množicami Nabor operatorjev Select, SelectMany OfType, Where Aggregate, Average, Count, LongCount, Max, Min, Sum Cast, OfType, ToArray, ToDictionary, ToList, ToLookup, ToSequence GroupBy, ToLookup Join, GroupJoin OrderBy, ThenBy, OrderByDescending, ThenByDescending, Reverse Concat, Distinct, Except, Intersect, Union Povpraševalni izrazi Nov koncept, ki ga uvaja LINQ, so povpraševalni izrazi (angl.»query Expressions«). Ta koncept prinaša v programski jezik možnost, da zapišemo povpraševanja LINQ v poenostavljeni obliki, ki močno spominja na SQL. Tako ni potrebno pisati standardnih povpraševalnih operatorjev enega za drugim z uporabo lambda izrazov, ampak lahko povpraševanje zapišemo v bolj berljivi obliki. var zaposleni = from zaposlen in awcontext.employees where zaposlen.hiredate > DateTime.Parse("1.1.2000") orderby zaposlen.contact.lastname ascending, zaposlen.contact.firstname ascending select zaposlen;
Zagotavljanje trajnosti objektov v ogrodju.net Stran 34 Primer 3.7 Povpraševalni izraz Ali uporabljamo povpraševalni izraze ali povpraševalne operatorje, je vseeno, saj prevajalnik pri prevajanju izvorne kode avtomatsko spremeni povpraševalne izraze v klice ustreznih povpraševalnih operatorjev. Tabela 3.2 prikazuje nabor povpraševalnih operatorjev, ki jih je mogoče v programskem jeziku C# 3.0 izraziti s povpraševalnimi izrazi. Žal smo pri uporabi povpraševalnih izrazov omejeni le na osnovne operatorje, kot so izbira, omejitev, združevanje, sortiranje in grupiranje. Tabela 3.2 Povpraševalni operatorji in pripadajoča C# sintaksa Povpraševalni operator GroupBy Join OrderBy Select Where C# sintaksa group by join in on equals orderby select where Drevo izrazov Drevo izrazov je posebnost različice LINQ to SQL v primerjavi z ostalimi različicami, saj edino LINQ to SQL deluje nad podatkovno bazo in ne nad pomnilnikom. Zaradi te razlike so se razvijalci odločili, da ta različica ne bo delovala nad IEnumerable, ampak so definirali novi vmesnik IQuerable. [16] Ta implementacija ima za posledico, da se klici povpraševalnih operatorjev ne izvedejo eden za drugim, ampak se gradi drevo izrazov (angl.»expression tree«). To drevo je podobno semantičnim drevesom, ki se uporabljajo pri prevajanju izvorne kode. Tudi tukaj ogrodje analizira zgrajeno drevo in na podlagi tega generira SQL-povpraševanje. To se nato pošlje v obdelavo na podatkovno bazo za obdelavo. Brez tega načina, bi potrebovali mnogo klicev do podatkovne baze za izvedbo povpraševanja. S tem bi po nepotrebnem povečali promet in obremenjevali tako strežnik kot odjemalca. Ne smemo pozabiti omeniti še ene pomembne značilnosti LINQ. To je odloženo izvajanje povpraševanj (angl.»deferred Query Execution«). Za razliko od ostale programske kode, ki se izvede v vrstnem redu, kakor je bila zapisana, se pri LINQ povpraševanja ne izvedejo, dokler se ne sprehodimo skozi rezultate, ali pa izrecno pokličemo metodo ToList ali
Zagotavljanje trajnosti objektov v ogrodju.net Stran 35 ToArray.[20] Tako se lahko zgodi, da za isto povpraševanje dobimo različne rezultate, če se je podatkovni vir med tem časom spremenil. 3.1.3 Preslikava Razvoj ogrodja.net 3.5, katerega del je tudi ogrodje LINQ to SQL, je tesno povezan z razvojem razvojnega okolja Visual Studio 2008, ki vključuje razne pripomočke, ki olajšajo delo z novim ogrodjem. Razen podpore prevajalnika in IntelliSense za pisanje LINQ povpraševanj, vsebuje še grafično orodje za urejanje preslikav med razredi, ki jim pravimo entitete, in tabelami (slika 3.2) ter orodje SqlMetal. Slika 3.2 Grafično orodje za načrtovanje LINQ to SQL entitet znotraj Visual Studia 2008 Grafično okolje omogoča predstavitev in urejanje datotek dbml, ki vsebujejo podatke o entitetah in njihovi preslikavi. Na podlagi te datoteke se za vsako entiteto avtomatično generira delni razred z vsemi atributi, kakor prikazuje primer 3.8. Uporablja se že uveljavljen način generiranja razredov, ki omogoča naknadno dopolnjevanje razredov z lastnimi delnimi razredi, ki vsebujejo specifično kodo.[21] Poleg entitet orodje generira še razred, ki deduje od razreda DataContext.
Zagotavljanje trajnosti objektov v ogrodju.net Stran 36 Ta razred služi kot izhodiščna točka za izvajanje povpraševanj, saj vsebuje povezave do zbirk, ki predstavljajo entitete, ki smo jih definirali s pomočjo grafičnega orodja. Poleg tega nudi funkcionalnost, ki je potrebna za vstavljanje in brisanje objektov ter sledenje sprememb na atributih. [Table(Name="HumanResources.Department")] public partial class Department : INotifyPropertyChanging, INotifyPropertyChanged { private static PropertyChangingEventArgs emptychangingeventargs = new PropertyChangingEventArgs(String.Empty); private short _DepartmentID; public Department() { OnCreated(); } [Column(Storage="_DepartmentID", AutoSync=AutoSync.OnInsert, DbType="SmallInt", IsPrimaryKey=true, IsDbGenerated=true)] public short DepartmentID { get { return this._departmentid; } set { if ((this._departmentid!= value)) { this.ondepartmentidchanging(value); this.sendpropertychanging(); this._departmentid = value; this.sendpropertychanged("departmentid"); this.ondepartmentidchanged(); } } } } Primer 3.8 Generiran razred Za preslikavo se privzeto uporablja atributno-usmerjeno preslikovanje (angl.»attribute- Based Mapping«). Preko anotacij na razredu in atributih ogrodje ugotovi, v katero tabelo se razred preslika. Drug način uporablja datoteko XML, v kateri je definirana preslikava. To datoteko je mogoče izdelati iz datoteke dbml in orodja SqlMetal [22], a pri tem načinu
Zagotavljanje trajnosti objektov v ogrodju.net Stran 37 moramo podati pot do datoteke ob vsakem klicu konstruktorja razreda DataContext. Tak način omogoča, da spremenimo preslikavo, ne da bi pri tem morali na novo prevesti izvorno kodo, a smo pri tem omejeni samo na manjše spremembe. Že dodajanje novega atributa zahteva ponovno generiranje vseh razredov in datoteke za preslikavo. 3.1.4 Posodabljanje, vstavljanje in brisanje Pri izdelavi objektov ogrodje nima večjih zahtev, poljubno lahko izdelujemo in manipuliramo z njimi. Le pri vstavljanju ali brisanju podatkov iz podatkovne baze je potrebno objekt registrirati pri vzorcu enota dela s klicem metod InsertOnSubmit ali DeleteOnSubmit, nato spremembe potrdimo še s klicem SubmitChanges metode. Department novoddelek = new Department() { Name = "Nov oddelek" }; awcontext.departments.insertonsubmit(novoddelek); awcontext.submitchanges(); awcontext.departments.deleteonsubmit(novoddelek); awcontext.submitchanges(); Primer 3.9 Dodajanje in odstranjevanje zapisov z uporabo LINQ to SQL 3.2 Ogrodje NHibernate 3.2.1 Iz Jave na.net Ob prihodu ogrodja.net, sprva v različici 1.0 in kasneje 2.0, se je pojavila potreba po ustreznem ogrodju za objektno-relacijsko preslikavo. Za zgled so se razvijalci obrnili na programsko ogrodje Java 2 Enterprise Edition, kjer je vodilno vlogo med objektnorelacijskimi preslikovalniki imelo ogrodje Hibernate.[23] Ker je bilo le-to odprtokodno in napisano v programskem jeziku, ki je zelo podoben C#, so lahko razvijalci začeli s prenosom programske kode na ogrodje.net. Razvoj na novem ogrodju se je začel leta 2004. Ko je leta 2005 izšla različica 1.0, ki je temeljila na starejši različici Hibernate 2.1, je NHibernate postal prvo ogrodje za objektno-relacijsko preslikavo na ogrodju.net. NHibernate ni bil samo prenos programske kode iz ene platforme na drugo, ampak je že od začetka vseboval tako lastnosti novejših različic ogrodja Hibernate, kakor tudi posebnosti programskega ogrodja.net.[2]
Zagotavljanje trajnosti objektov v ogrodju.net Stran 38 Slika 3.3 Arhitektura ogrodja NHibernate [24] NHibernate je zbirka knjižnic, ki omogočajo preslikavo objektov v relacijsko podatkovno bazo. Temelji na principu POCO ali»plain Old CLR Object«, kar je izpeljanka iz javanske različice POJO ali»plain Old Java Object«, in pomeni, da ogrodje ne zahteva posega v entitete za izvedbo preslikave. Kot prikazuje slika 3.3, je aplikacija neodvisna od ogrodja. Edini vezni člen so trajni objekti (angl.»persistent objects«), za katere ogrodje ureja preslikavo v podatkovno bazo. Vsa preslikava je zapisana v meta podatkih, ki so v tem primeru shranjeni v dokumentih tipa XML. Izsek datoteke, ki opisuje preslikavo razreda Contact, je prikazan v primer 3.10. <hibernate-mapping xmlns="urn:nhibernate-mapping-2.0" namespace="diploma.nhibernate" assembly="diploma.nhibernate"> <class name="contact" table="contact"> <id name="contactid" type="int32" column="contactid" > <generator class="identity" /> </id> <property name="firstname"> <column name="firstname" /> </property> <property name="middlename"> <column name="middlename" /> </property> <property name="lastname"> <column name="lastname" /> </property> <set name="employeelist" lazy="true"> <key column="contactid" />
Zagotavljanje trajnosti objektov v ogrodju.net Stran 39 <one-to-many class="employee" /> </set> <one-to-one name="adress" class="adress" cascade="all" /> </class> </hibernate-mapping> Primer 3.10 Opis preslikave v datoteki hbm Prednost te rešitve je, da gradimo neodvisen poslovni domenski model, in ga nato preslikamo v novo ali že obstoječo podatkovno bazo. Razrede lahko pišemo na roko ali generiramo, na primer iz razrednega diagrama. Edina zahteva ogrodja je, da za vsak razred, ki bo preslikan v relacijsko podatkovno bazo, ustvarimo datoteko hbm, v kateri navedemo, kako se posamezni atributi in relacije preslikajo v atribute tabele. Osnovni elementi preslikave so navedeni v tabeli 3.3tabela 3.3.[25] Tabela 3.3 Osnovni elementi preslikave in njihov pomen XML element hibernate-mapping class id property set, bag, map, list one-to-one many-to-one component subclass joined-subclass union-subclass join Pomen Vrhnji element Ime razreda in tabele, v katero se preslika Identifikator Ime in tip atributa ter ime atributa, v katerega se preslika Preslikava relacije mnogo proti ena ali mnogo proti mnogo, uporaba zbirk Preslikava relacije ena proti ena Preslikava relacije mnogo proti ena Preslikava vrednostnih objektov, iz ene tabelo preslikamo v več razredov Preslikava dedovanja, strategija ena tabela za vse razrede Preslikava dedovanja, strategija tabela na razred Preslikava dedovanja, strategija tabela na konkreten razred Preslikava atributov iz več tabel v en razred Za uporabo ogrodja, razen hbm datotek, potrebujemo sejno tovarno, ki je primerek vmesnika ISessionFactory. Ob nastanku tovarna analizira vse hbm datoteke in na podlagi teh zgradi ustrezne pomnilniške strukture. To je procesorsko zelo potratno, zato poizkušamo to znotraj življenjskega cikla aplikacije, narediti samo enkrat in zadržati skozi celotno trajanje aplikacije. Kot lahko sklepamo že iz imena, služi sejna tovarna za pridobivanje primerkov vmesnika ISession. Seja je ključnega pomena pri operiranju s podatkovno bazo, saj služi kot osrednja točka za pridobivanje, vstavljanje, urejanje in brisanje podatkov.[26]
Zagotavljanje trajnosti objektov v ogrodju.net Stran 40 3.2.2 Povpraševanja NHibernate ponuja več načinov, kako pridobivamo podatke iz podatkovne baze: [26] navigacija preko drevesa objektov, dele katerega smo prej naložili iz podatkovne baze, pridobivanje objektov preko njihovega identifikatorja, uporaba jezika za povpraševanje Hibernate Query Language ali HQL, uporaba kriterijskih povpraševanj (angl.»criteria Queries«) preko vmesnika ICriteria in uporaba standardnega povpraševalnega jezika SQL. Ker je pridobivanje objektov preko njihovega identifikatorja, jezika SQL in navigacije skozi drevo objektov zelo preprosto, se bomo v nadaljevanju osredotočili predvsem na povpraševalni jezik HQL in kriterijsko povpraševanje. Hibernate Query Language Povpraševalni jezik HQL je v celoti prevzet po javanski različici ogrodja. Razlog za to je zagotovo dobra sprejetost, ki ga je jezik doživel že s prvimi različicami ogrodja Hibernate. K temu zagotovo pripomore podobnost s povpraševalnim jezikom SQL, po katerem HQL povzema večino sintakse. Razlika je le v tem, da HQL ne deluje na nivoju relacijskih atributov in tabel, ampak atributov in razredov. Za povpraševanja ogrodje ponuja vmesnik IQuery, preko katerega vstavljamo parametre, omejimo število zadetkov in določimo, da poizvedba vrne samo unikatne rezultate. Primerek vmesnika pridobimo s klicem metode CreateQuery, ki mu kot parameter podamo povpraševalni izraz v jeziku HQL. Tudi NHibernate implementira odloženo izvajanje povpraševanja. To pomeni, da se HQL-poizvedba analizira in proži šele ob klicu metode List. Kot lahko vidimo iz primera 3.11, je sintaksa jezika zelo podobna SQL. Manjka le ključna besedica select, ki določa izbiro atributov v tabeli. Te v HQL ne potrebujemo, če želimo, da povpraševanje vrne samo primerke enega razreda. Jezik tudi omogoča uporabo projekcije, vendar v takem primeru povpraševanje vrne polje objektov tipa object.
Zagotavljanje trajnosti objektov v ogrodju.net Stran 41 string querystring = @"from Employee emp where emp.manager=:manager"; IQuery query = session.createquery(querystring).setparameter("manager", manager, NHibernateUtil.Entity(typeof(Employee))); query.list(zaposleni); Primer 3.11 Povpraševanje z jezikom HQL Med drugim HQL ponuja že poznane konstrukte jezika SQL, kot so združevanja, sortiranje, grupiranje, gnezdena povpraševanja, itd. Najverjetneje je tudi to vzrok za veliko sprejetost ogrodja. Kot posebnost jezika bi poudarili možnost, da kot parametre poizvedbe vstavimo objekte, kot prikazuje primer 3.11. Ogrodje avtomatsko poišče identifikator objekta in ga ustrezno vstavi v povpraševalni niz. Tako na preprost način poiščemo vse zaposlene, čeprav v razredu Employee nismo definirali relacije na Employees. Kot smo ugotovili, lahko z jezikom HQL izrazimo najrazličnejše poizvedbe, zaradi česar je zagotovo neizogiben pri uporabi ogrodja NHibernate, vendar ima veliko slabost. Ta je, da so vse poizvedbe napisane v nizu. Ta slabost je poznana razvijalcem, ki dostopajo do podatkovne baze preko ogrodja ADO.NET in so primorani pisati SQL poizvedbe v programski kodi. To je zagotovo velika slabost, saj v takem primeru nimamo podpore prevajalnika, kar pa je, glede na to, da pišemo poizvedbe nad objekti, skoraj nujno potrebno. Kot rešitev so razvijalci razvili kriterijsko povpraševanje, ki omogoča strogo tipizirano povpraševanje. Kot zanimivost lahko omenimo, da je zaradi razširljivosti, ki jih ponuja tehnologija LINQ, že bil razvit dodatek LINQ to NHibernate. Ta omogoča pisanje strogo tipiziranih poizvedb s tem, da LINQ-poizvedbe pretvori v klice metod kriterijskega povpraševanja.[27] Kriterijsko povpraševanje Drug način povpraševanja ponuja Criteria Query API. Le-ta je namenjen razvijalcem, ki jim je bližji objektni pristop ali niso dovolj izkušeni v jeziku SQL. Omogoča, da zapišemo poizvedbo na strogo tipiziran način z uporabo kriterijev ali primerka razreda. Ne glede na to, kateri način bomo izbrali, potrebujemo metode, ki jih ponuja vmesnik ICriteria. Preko tega dostopamo do funkcionalnosti, ki omogoča gradnjo poizvedb s klici ustreznih metod. [25]
Zagotavljanje trajnosti objektov v ogrodju.net Stran 42 Omejitve lahko izrazimo z uporabo kriterijev ali primerkov. Prvi uporablja»query by criteria«. Pri tem definiramo omejitve v obliki izrazov, ki jih definira razred NHibernate.Criterion.Expression. To so izrazi kot večje, manjše, enako ali primerljivo in jih najdemo v povpraševalnih jezikih, kot sta SQL in HQL.[26] Tako povpraševanje je prikazano v primeru 3.12primer 3.12, kjer iščemo vse osebe, ki jim je ime Janez. ICriteria kriterij = session.createcriteria(typeof(person)).add(expression.like("firstname", "Janez", MatchMode.Exact)).AddOrder(Order.Desc("Birthdate")); Primer 3.12 Poizvedba z uporabo»query by criteria«drugi,»query by example«, temelji na primerkih razredov. Namesto da bi omejili vsak atribut posebej, lahko ustvarimo primerek razreda in ustrezno nastavimo atribute. Ta primerek nato služi kot vzorec, po katerem išče poizvedba.[26] Če n-terica ustreza vzorcu se vrne, v nasprotnem primeru se premakne na naslednjo vrstico. Primer 3.13 prikazuje enako povpraševanje kot prej, le da kriterij uporablja primerek razreda. Person janez = new Person(); janez.firstname = "Janez"; ICriteria kriterij = session.createcriteria(typeof(person)).add(example.create(janez)); Primer 3.13 Poizvedba z uporabo»query by example«3.2.3 Posodabljanje, vstavljanje in brisanje V ogrodju sta kot del seje, implementirana vzorca enota dela in slovar identitet. Nove objekte, ki jim želimo zagotoviti hrambo, moramo najprej registrirati pri enoti dela s klicem metode Save. Ta bo avtomatično poskrbela, da se bo vsebina objekta shranila v podatkovno bazo, ko bomo končali z delom in poklicali metodo Flush. Enako kot smo objekt shranili, ga lahko tudi izbrišemo. Pokličemo le ustrezno metodo Delete in kot parameter dodamo objekt, ki ga želimo izbrisati. Pri sledenju spremembam moramo poznati značilnost ogrodja, kajti seja skrbi za sledenje samo, dokler je ta odprta. V večini primerov se uporablja tako imenovani odklopljen način, kjer v eni seji preberemo
Zagotavljanje trajnosti objektov v ogrodju.net Stran 43 podatke in jih v drugi seji shranim. V takem primeru moramo poklicati metodo Update ali SaveOrUpdate.[26] 3.3 Ogrodje ADO.NET Entity Framework 3.3.1 Arhitektura ogrodja ADO.NET Entity Framework Ogrodje ADO.NET Entity Framework je najnovejše od vseh tukaj predstavljenih ogrodij. Prvi osnutki ogrodja so bili predstavljeni na konferenci TechEd leta 2006. Njegova končna različica je izšla julija 2008, ko je Microsoft izdal prvi paket posodobitev za Visual Studio 2008 in ogrodje.net 3.5. V nadaljevanju podpoglavja sledi opis vseh glavnih komponent arhitekture ogrodja ADO.NET Entity Framework, katerega sestavlja več funkcionalnih komponent. Najpomembnejše so: [28] objektne storitve, entitetni podatkovni model, ponudnik podatkov na nivoju entitet in ponudniki podatkov za specifične podatkovne shrambe.
Zagotavljanje trajnosti objektov v ogrodju.net Stran 44 Slika 3.4 Arhitektura ogrodja ADO.NET Entity Framework Objektne storitve Najbolj izpostavljena komponenta ogrodja so zagotovo objektne storitve (angl.»object Services«). Objektne storitve so postavljene čisto na vrh ogrodja in zagotovo nudijo funkcionalnost, ki jo uporablja največ razvijalcev. Omogočajo namreč, da uporabljamo CLR-objekte, ki temeljijo na entitetah iz entitetnega podatkovnega modela. Objektne storitve ponujajo razred EntityObject, od katerega dedujejo vsi razredi, ki jih ustvari generator na podlagi entitetnega podatkovnega modela. Preko tega razreda omogočajo funkcionalnost ustvarjanja objektov, ki so rezultat povpraševanja, sledenja spremembam na teh objektih, upravljanja relacij in shranjevanja sprememb v podatkovno bazo. Objektne storitve torej ponujajo vso funkcionalnost objektno-relacijske preslikave. Samo ogrodje je zasnovano na način, ki omogoča vključitev različnih programskih slojev nad entitetnim podatkovnim modelom, ki ga omogoča ponudnik podatkov na nivoju entitet. Tako je komponenta objektnih storitev samo ena izmed takšnih programskih slojev,
Zagotavljanje trajnosti objektov v ogrodju.net Stran 45 ki entitete predstavi kot strogo tipizirane CLR-objekte in predstavlja funkcionalnost objektno-relacijske preslikave.[29] Entitetni podatkovni model Entitetni podatkovni model (angl.»entity Data Model«ali EDM) bomo podrobneje opisali v naslednjem poglavju. Tukaj naj samo omenimo, da je to najpomembnejši del ogrodja, saj kot trdijo avtorji [30], ustvarja konceptualni nivo, kar je nadgradnja entitetno-relacijskega modela, ki ga je v sedemdesetih letih 20. stoletja uvedel dr. Peter Chena.[28] Ponudnik podatkov na nivoju entitet Druga pomembna komponenta je ponudnik podatkov na nivoju entitet ali EntityClient. Ime spominja na SqlClient, ki je implementacija ponudnika podatkov (angl.»data Provider«) za podatkovno bazo SQL Server. Tako je tudi EntityClient implementacija takega ponudnika, vendar na višjem nivoju. Ta ne skrbi za povezavo in poizvedbe nad podatkovno bazo, ampak deluje na nivoju entitetnega podatkovnega modela. Knjižnico lahko uporabljamo direktno, ali z uporabo objektnih storitev, ki ležijo nad njim. Potrebno je poudariti, da je le EntityClient zmožen izvajanja povpraševanj. Objektne storitve nudijo le vmesnik, kako dostopamo do povpraševanj na objektni način. Razlika je v tem, da EntityClient poizvedbe vračajo rezultate v tabelarični obliki, medtem ko objektne storitve transformirajo rezultat v objekte. Poleg tega rezultate, ki jih vrača EntityClient, lahko samo beremo. Samo objektne storitve nudijo funkcionalnost sledenja spremembam in shranjevanja le-teh nazaj v podatkovno bazo. [29] Ponudniki podatkov za specifične podatkovne shrambe Ogrodje ADO.NET Entity Framework gradi na ponudnikih (angl.»provider«) za specifične podatkovne shrambe, poznanih že iz ogrodja ADO.NET. Te komponente gradijo na standardiziranem vzorcu».net Framework Data Provider«in omogočajo dostop do posameznih podatkovnih baz. Tako vsak proizvajalec podatkovne baze implementira svojega ponudnika, kjer zajame specifike svojega proizvoda. [28] [29] Ob predstavitvi ogrodja je Microsoft posodobil svoj SqlClient API, da podpira preoblikovanje povpraševanj in ukazov nad entitetnim modelom v povpraševanja in ukaze podatkovne baze. Ta knjižnica omogoča povezovanje na strežnike SQL Server 2000, 2005
Zagotavljanje trajnosti objektov v ogrodju.net Stran 46 in 2008. V tem trenutku obstajajo posodobljeni ponudniki že za podatkovne baze proizvajalcev Oracle, IBM, MySQL, SQLite in drugih.[28] Trenutno je največji poudarek na relacijskih podatkovnih bazah, vendar arhitektura ogrodja omogoča vključitev ponudnikov tudi za druge podatkovne vire, kot so datoteke XML ali spletne storitve.[28] Poleg naštetih arhitekturnih komponent ne smemo izpustiti grafičnega orodja, ki je del Visual Studia 2008 SP1. Ta omogoča grafično predstavitev entitetnega podatkovnega modela, urejanje entitet in preslikav ter dodajanje shranjenih procedur. Prav tako lahko z vključenim čarovnikom generiramo entitete na podlagi tabel v podatkovni bazi. 3.3.2 Entitetni podatkovni model Zaradi pomembnosti modela, smo se odločili, da posvetimo celotno poglavje entitetnemu podatkovnemu modelu (angl.»entity Data Model«ali krajše EDM). Entitetni podatkovni model predstavlja most med aplikacijo in podatkovno shrambo. Omogoča višji nivo abstrakcije, saj delujemo nad konceptualnim modelom podatkov in ne nad tabelami podatkovne baze. EDM gradi na osnovi entitetno-relacijskega modela, ki ga je iznašel dr. Peter Chen. Ta je definiral konceptualni podatkovni model (angl.»conceptual Data Model), ki so ga razvijalci uporabljali za lažjo predstavitev sheme podatkovne baze.[30] EDM nadgrajuje ta model in ga prenaša v dokumente XML, ki jih lahko uporabljajo različni programski modeli. Prednost tega modela in tudi razlog, zakaj je to novost, je način načrtovanja informacijskih sistemov. Uporaba EDM omogoča, da lahko začnemo sistem načrtovati od spodaj navzgor, kar pomeni, da izhajamo iz podatkovne baze. Iz nje generiramo razrede in jih optimiziramo. Lahko pa uberemo tudi obratno pot. Se pravi načrtovanje od zgoraj navzdol. Tako lahko začnemo načrtovati entitete brez podatkovne baze in jih šele na koncu preslikamo v tabele. Najpogosteje se uporablja tretji način, ki je kombinacija obeh prej navedenih. Ta način se imenuje»meet in the middle«, kjer sočasno gradimo entitetni in razredni model, ter na koncu po potrebi prilagodimo preslikavo.
Zagotavljanje trajnosti objektov v ogrodju.net Stran 47 Slika 3.5 Grafično orodje za načrtovanje entitetnega podatkovnega modela Za urejanje entitetnega podatkovnega modela nudi Visual Studio 2008 SP1 polno podporo, saj ima vgrajeno grafično orodje za delo z datotekami edmx. To omogoča, da na lahek način ustvarimo entitete, urejamo njihove lastnosti, dodajamo shranjene procedure in urejamo preslikavo. Na sliki 3.5 vidimo razrede, ki jim pravimo entitete, in relacije med njimi. Entitete so sestavljene iz atributov in navigacijskih atributov, ki določajo ime relacije. Privzeto so vse relacije dvosmerne. Tako ima entiteta Employee povratno relacijo na sebe, ki predstavlja relacijo med nad- in podrejenim. Za pridobitev nadrejenega uporabimo navigacijski atribut Manager, če pa želimo pridobiti seznam podrejenih, uporabimo atribut Employees. Kot smo videli, nudi grafično orodje znotraj Visual Studia 2008 SP1 podporo samo za konceptualni model. Za lažje razumevanje preslikave in celotnega EDM bomo na kratko predstavili še XML-strukturo edmx-datoteke. V bistvu je ta datoteka sestavljena iz dveh delov. Prvi določa tri sheme, ki predstavljajo konceptualni in podatkovni model ter preslikavo. Drugi del, ki je omejen z elementom edmx:designer, uporablja grafično orodje za shranjevanje pozicije entitet na zaslonu. Ker je ta za delovanje ogrodja popolnoma nepomembna, jo bomo preskočili in se povsem posvetili prvemu delu.
Zagotavljanje trajnosti objektov v ogrodju.net Stran 48 Slika 3.6 Struktura meta podatkov Kot smo že na začetku povedali, so vse tri sheme v času načrtovanja združene v eno (slika 3.6). Komaj prevajalnik jih razdruži in ustvari tri ločene datoteke. Tako se konceptualna shema shrani v datoteko s končnico csdl, kar pomeni»conceptual Schema Definition Language«. Podatkovna shema se shrani v datoteko s končnico ssdl, kar pomeni»storage Schema Definition Language«in tudi preslikava se shrani v svojo datoteko s končnico msl, kar pomeni»mapping Specification Language«. V literaturi pogosto najdemo te oznake za posamezne sheme. Najprej bomo na kratko predstavili konceptualni model, izsek katerega prikazuje primer 3.14. Znotraj schema elementa lahko vidimo element EntityContainer. Ta služi kot ovoj za elemente EntitySet in AssociationSet. EntitySet predstavlja skupno definicijo za vse entitete. Za lažje razumevanje si pomagajmo s primerjavo iz objektno orientiranega razvoja. EntitySet predstavlja razred, ki ga določa tip EntityType. Entitete so primerki tega razreda oziroma objekti. Tip entitete je določen v razdelku EntityType, ki vsebuje elemente Key, Property in NavigationProperty. Vsaka entiteta mora imeti ključ, na podlagi katerega se loči od ostalih entitet. Navadno je to kar primarni ključ iz relacijske tabele. Sledijo še ostali atributi entitete s pripadajočim podatkovnim tipom. Tukaj moramo poudariti, da ogrodje uporablja svoje podatkovne tipe, a so ti tesno povezani s podatkovnimi tipi ogrodja.net. Zadnji del entitetnega tipa zavzemajo navigacijski atributi. Če ima entiteta relacijo z drugo, lahko ustvarimo navigacijski atribut, ki je tesno povezan z asociacijo.
Zagotavljanje trajnosti objektov v ogrodju.net Stran 49 Asociacije predstavljajo relacijo med dvema entitetama. V shemi csdl je za to uporabljen element Association, ki definira končni točki relacije. Kakor so tudi entitete združene v množice, so tudi asociacije združene v elementu AssociationSet. To je na prvi pogled lahko zavajajoče, vendar je povezano s tem, kako objektno orientirani jeziki predstavljajo relacije. Ti namreč relacije obravnavajo kot objekte, tako bo vsako relacijo med objektom Employee in DepartmentHistory predstavljal en FK_DepartmentHistory_DepartmentID relacijski objekt.[28] <edmx:conceptualmodels> <Schema Namespace="AWModel" Alias="Self"> <EntityContainer Name="AWEntities"> <EntitySet Name="Departments" EntityType="AWModel.Department" /> <AssociationSet Name="FK_DepartmentHistory_DepartmentID" Association="AWModel.FK_DepartmentHistory_DepartmentID"> <End Role="Department" EntitySet="Department" /> <End Role="EmployeeDepartmentHistory" EntitySet="EmployeeDepartmentHistory" /> </AssociationSet> </EntityContainer> <EntityType Name="Department"> <Key> <PropertyRef Name="DepartmentID" /> </Key> <Property Name="DepartmentID" Type="Int16" Nullable="false" /> <Property Name="Name" Type="String" Nullable="false" MaxLength="50" Unicode="true" FixedLength="false" /> <NavigationProperty Name="DepartmentHistory" Relationship="AWModel.FK_DepartmentHistory DepartmentID" FromRole="Department" ToRole="DepartmentHistory" /> </EntityType> <Association Name="FK_DepartmentHistory_DepartmentID"> <End Role="Department" Type="AWModel.Department" Multiplicity="1" /> <End Role="DepartmentHistory" Type="AWModel.DepartmentHistory" Multiplicity="*" /> <ReferentialConstraint> <Principal Role="Department"> <PropertyRef Name="DepartmentID" /> </Principal> <Dependent Role="DepartmentHistory"> <PropertyRef Name="DepartmentID" /> </Dependent> </ReferentialConstraint> </Association> </Schema> </edmx:conceptualmodels> Primer 3.14 Izsek iz CSDL sheme
Zagotavljanje trajnosti objektov v ogrodju.net Stran 50 Podatkovna ali ssdl shema je namenjena opisu podatkovne shrambe. Elementi za opis so enaki kot v konceptualni shemi, vendar imajo drug pomen. Za opis tabel in atributov sta uporabljena elementa EntityType in Property, za tuje ključe in referenčne omejitve element Associtaion in podelement ReferentialConstraint. Kot opazimo v primeru 3.15, so v tej shemi podatkovni tipi drugačni od tistih, ki smo jih opazili v prejšnjem primeru, in predstavljajo podatkovne tipe podatkovne baze. <edmx:storagemodels> <Schema Namespace="AWModel.Store" Alias="Self" Provider="System.Data.SqlClient" ProviderManifestToken="2008"> <EntityContainer Name="AWModelStoreContainer"> <EntitySet Name="Department" EntityType="AWModel.Store.Department" store:type="tables" /> <AssociationSet Name="FK_Employee_Contact " Association="AWModel.Store.FK_Employee_Contact "> <End Role="Contact" EntitySet="Contact" /> <End Role="Employee" EntitySet="Employee" /> </AssociationSet> </EntityContainer> <EntityType Name="Department"> <Key> <PropertyRef Name="DepartmentID" /> </Key> <Property Name="DepartmentID" Type="smallint" Nullable="false" StoreGeneratedPattern="Identity" /> <Property Name="Name" Type="nvarchar" Nullable="false" MaxLength="50" /> </EntityType> <Association Name="FK_Employee_Contact "> <End Role="Contact" Type="AWModel.Store.Contact" Multiplicity="1" /> <End Role="Employee" Type="AWModel.Store.Employee" Multiplicity="*" /> <ReferentialConstraint> <Principal Role="Contact"> <PropertyRef Name="ContactID" /> </Principal> <Dependent Role="Employee"> <PropertyRef Name="ContactID" /> </Dependent> </ReferentialConstraint> </Association> </Schema> </edmx:storagemodels> Primer 3.15 Izsek iz SSDL sheme
Zagotavljanje trajnosti objektov v ogrodju.net Stran 51 Zadnji del entitetnega podatkovnega modela vsebuje definicijo preslikav. Medtem ko csdl in ssdl shemi služita le opisu entitet oziroma tabel, je msl shema namenjena preslikavi. V tem dokumentu je namreč določeno, kako se bodo atributi entitet preslikali v atribute tabel. Za opis tega je uporabljeni elementi EntitySetMapping, EntityTypeMapping in MappingFragment. Prva dva določata entitetni set in tip, medtem ko MappingFragment določa, kako se preslikajo posamezni atributi. V primeru 3.16 morda ni najbolj razvidna uporaba tega, a lahko povemo, da je možno več tabel preslikati v eno entiteto. V takem primeru bi potrebovali več MappingFragment elementov. <edmx:mappings> <Mapping Space="C-S"> <EntityContainerMapping StorageEntityContainer="AWModelStoreContainer" CdmEntityContainer="AWEntities"> <EntitySetMapping Name="Department"> <EntityTypeMapping TypeName="IsTypeOf(AWModel.Department)"> <MappingFragment StoreEntitySet="Department"> <ScalarProperty Name="DepartmentID" ColumnName="DepartmentID" /> <ScalarProperty Name="Name" ColumnName="Name" /> <ScalarProperty Name="DepartmentName" ColumnName="DepartmentName" /> </MappingFragment> </EntityTypeMapping> </EntitySetMapping> </EntityContainerMapping> </Mapping> </edmx:mappings> Primer 3.16 Izsek iz MSL sheme To je bil le kratek pregled vsebine shem, ki jih uporablja ogrodje. Celotna dokumentacija je na voljo na [31]. Glede shem lahko še dodamo, da lahko uporabimo tudi zunanjo shemo. Microsoft je pripravil orodje EdmGen, ki omogoča generiranje shem na osnovi podatkovne baze in razredov na osnovi konceptualnega modela.[32] Če želimo uporabiti zunanjo shemo, moramo v konstruktorju razreda ObjectContext podati pot do datotek. Če uporabljamo ogrodje znotraj Visual Studia 2008 SP1, ta avtomatsko vključi sheme v zbirko in generira razrede na podlagi entitet iz konceptualnega modela. Kot vidimo v primeru 3.17, ti razredi ne ustrezajo principu POCO. Opazimo lahko dedovanje, anotacije in veliko kode pri dostopu do javnih atributov.
Zagotavljanje trajnosti objektov v ogrodju.net Stran 52 [EdmEntityTypeAttribute(NamespaceName="AWModel", Name="Contact")] public partial class Contact : EntityObject { public static Contact CreateContact(int contactid,string firstname ) { } [EdmScalarPropertyAttribute(IsNullable=false)] public string FirstName { get { return this._firstname; } set { this.onfirstnamechanging(value); this.reportpropertychanging("firstname"); this._firstname = SetValidValue(value, false); this.reportpropertychanged("firstname"); this.onfirstnamechanged(); } } private string _FirstName; partial void OnFirstNameChanging(string value); partial void OnFirstNameChanged(); [EdmRelationshipNavigationPropertyAttribute("AWModel", "FK_Employee_ContactID", "Employee")] public EntityCollection<Employee> Employees { get { return ((IEntityWithRelationships)(this)).RelationshipManager.GetRelatedCollec tion<employee>("awmodel.fk_employee_contactid", "Employee"); } set { if ((value!= null)) { ((IEntityWithRelationships)(this)).RelationshipManager.InitializeRelate dcollection<employee>("awmodel.fk_employee_contactid", "Employee", value); } } } } Primer 3.17 Generirana koda iz EDM Generirane razrede lahko nadgradimo z lastnimi metodami, tako da implementiramo delni razred, ki dopolnjuje generiranega. Ogrodje omogoča tudi različne razširitvene točke, kjer lahko nadgradimo razrede. Za primer lahko navedemo delne metode, ki so novost
Zagotavljanje trajnosti objektov v ogrodju.net Stran 53 programskega jezika C# 3.0 [33], in jih ogrodje generira za vsak atribut. Z dopolnitvijo metod OnImeAtributaChanging in OnImeAtributaChanged lahko dopolnimo dostope do atributov z lastno kodo. Ogrodje Entity Framework omogoča tudi vključevanje lastnih razredov, vendar so za to potrebni posegi v kodo razreda. Najprej mora razred dedovati od EntityObject. Ker ogrodje.net podpira samo enkratno dedovanje, se lahko zgodi, da razred že deduje od katerega drugega. Zaradi tega so razvijalci ogrodja ponudili drugo možnost z implementacijo vmesnikov. Če želimo uporabiti funkcionalnost ogrodja, potrebujemo vmesnike IEntityWithKey, IEntityWithChangeTracker in IEntityWithRelationships. Kot lahko razberemo iz imen vmesnikov, le-ti nudijo funkcionalnost identifikacije entitet s pomočjo ključa, sledenje spremembam in upravljanja z relacijami. Razvijalci so ta princip poimenovali IPOCO, kar pomeni POCO z vmesniki.[28] Vendar to ne drži popolnoma, saj ogrodje zahteva še večje posege v kodo. Za primer lahko povemo, da je potrebno vse dostope do atributov dopolniti s kodo, ki signalizira spremembo atributa. 3.3.3 Poizvedbe Povpraševanja ločimo glede na tista, ki uporabljajo objektne storitve, in tista, ki izvajajo povpraševanja z uporabo ponudnika podatkov na nivoju entitet (»EntityClient provider«). Pri tem je potrebno poudariti, da se vsa povpraševanja izvajajo nad entitetami EDM in ne tabelami podatkovne baze. Objektne storitve uporabljata LINQ to Entities in Entity SQL. LINQ to Entities je različica tehnologije LINQ, ki omogoča pisanje LINQ poizvedbe nad entitetami EDM. Ker smo tehnologijo LINQ že izčrpno opisali v prejšnjih poglavjih, bomo tukaj predstavili samo primer poizvedbe. AdventureWorksEntities awentities = new AdventureWorksEntities(); var delavci = from zaposlen in awentities.employees.include("contact") where zaposlen.hiredate >= hiredate orderby zaposlen.contact.lastname ascending, zaposlen.contact.firstname ascending select zaposlen;
Zagotavljanje trajnosti objektov v ogrodju.net Stran 54 Primer 3.18 Poizvedba LINQ to Entities Kot vidimo v primeru 3.18, LINQ to Entities uporablja poznano sintakso LINQ. V tem primeru razred AdventureWorksEntities, ki deduje od razreda ObjectContext, vsebuje referenco na razred ObjectQuery<Employee>. Ta razred implementira vmesnik IQuerable, ki omogoča izgradnjo drevesa izrazov, iz katerega ogrodje ustvari poizvedbe SQL. Ime razreda, ki deduje od ObjectContext, je definirano v konceptualni shemi csdl, kot element EntityContainer. Tudi reference na objektne poizvedbe so določene v tej datoteki kot elementi EntitySet. Druga možnost izvajanja poizvedb s pomočjo objektnih storitev je uporaba jezika Entity SQL. Jezik je zelo podoben jeziku SQL, vendar s to razliko, da v poizvedbah uporablja entitete, atribute in asociacije, definirane v konceptualnem modelu. Primer 3.19 prikazuje uporabo Entity SQL za izvedbo enake poizvedbe kot v prejšnjem primeru. Ključno vlogo v tem primeru ima razred ObjectQuery, ki omogoča izvajanje poizvedb, zapisanih v jeziku Entity SQL s pomočjo objektnih storitev. string q = "SELECT VALUE e FROM Employees AS e WHERE e.hiredate >= @hiredate ORDER BY e.contact.lastname ASC, e.contact.firstname ASC"; var zaposleni = awentities.createquery<employee>(q); zaposleni.parameters.add(new ObjectParameter("hireDate", hiredate)); Primer 3.19 Poizvedba z uporabo Entity SQL in objektnih storitev Kakor smo navajeni iz tehnologije LINQ, lahko tudi poizvedbe v Entity SQL izrazimo z zaporedjem metod. Te metode se imenujejo graditelji poizvedb (angl.»query Builder«) in le delno podpirajo vse funkcionalnosti jezika Entity SQL. Kot pove že ime, graditelji poizvedb gradijo primerek razreda ObjectQuery, ki izvede povpraševanje. V primeru 3.20 vidimo povpraševanje z uporabo graditeljev poizvedb. Poizvedba je enaka kot v prejšnjih primerih. var zaposleni = awentities.employees. Where("it.HireDate >= @hiredate"). OrderBy("it.Contact.LastName ASC, it.contact.firstname ASC"); zaposleni.parameters.add(new ObjectParameter("hireDate", hiredate)); Primer 3.20 Poizvedba z uporabo Entity SQL in graditeljem poizvedb
Zagotavljanje trajnosti objektov v ogrodju.net Stran 55 Objektne storitve niso edini način, kako izvajamo poizvedbe. Drug način je možen z uporabo jezika Entity SQL in ponudnika podatkov na nivoju entitet (EntityClient). EntityClient se razlikuje od objektnih storitev v tem, da ne materializira podatkov v objekte, ampak rezultat poizvedbe vrne zapise. EntityClient implementira vzorec ponudnika podatkov (angl.»data Provider«), ki je poznan že iz ogrodja ADO.NET. Tako tudi EntityClient ponuja znane razrede, ki skrbijo za povezavo (EntityConnection), poizvedbe (EntityCommand) in parametre (EntityParameter) [29], katerih uporaba je prikazana v primeru 3.21. Za pridobivanje podatkov potrebujemo primerek razreda EntityDataReader, ki deduje od razreda DbDataReader. Za razliko od standardnih implementacij, ki znajo vračati samo primitivne podatkovne tipe, ima EntityDataReader zmožnost, da kot rezultat poizvedbe vrne objekte tipa DbDataRecord, ki predstavljajo zapis iz objekta DbDataReader.[28] string q = "SELECT VALUE e FROM AWEntities.Employees AS e WHERE e.hiredate >= @hiredate ORDER BY e.contact.lastname ASC, e.contact.firstname ASC"; using (EntityConnection conn = new EntityConnection("name=AWEntities")) { conn.open(); EntityCommand cmd = conn.createcommand(); cmd.commandtext = q; EntityParameter param = new EntityParameter(); param.parametername = "hiredate"; param.dbtype = DbType.DateTime; param.value = hiredate; cmd.parameters.add(param); using (EntityDataReader rdr = cmd.executereader(commandbehavior.sequentialaccess)) { while (rdr.read()) { int employeeid = rdr.getint32(0); } } conn.close();
Zagotavljanje trajnosti objektov v ogrodju.net Stran 56 } Primer 3.21 Poizvedba z uporabo Entity SQL in ponudnika podatkov na nivoju entitet Treba je tudi poudariti, da jezik Entity SQL ne ponuja možnosti vstavljanja, posodabljanja in brisanja podatkov. Samo objektne storitve nudijo funkcionalnost vstavljanja, sledenja spremembam in posodabljanja ter brisanja entitet. Kako natančno, bomo predstavili v naslednjem poglavju. 3.3.4 Posodabljanje, vstavljanje in brisanje Ogrodje Entity Framework ima poseben način, kako skrbi za osnovne operacije, kot so posodabljanje, vstavljanje in brisanje entitet. Ob vsaki poizvedbi nad objektnimi storitvami ogrodje poskrbi, da iz rezultatov poizvedbe ustvari ustrezne objekte. Za vsak objekt se izdela ustrezen objekt tipa ObjectStateEntry. Ta objekt hrani trenutno in prvotno vsebino objekta ter zastavico EntityState, ki signalizira, v kakšnem stanju je objekt. Vrednosti zastavice so lahko: nespremenjen (Unchanged), spremenjen (Modified), dodan (Added) in izbrisan (Deleted).[28] Če spremenimo objekt, se ta sprememba signalizira ustreznemu objektu ObjectStateEntry. Tam se popravi trenutna vrednost in zastavica se nastavi na stanje spremenjen. Pri klicu metode SaveChanges ogrodje preveri vse objekte na njihovo stanje. Če ugotovi, da se je objekt spremenil, preveri, kateri atributi so bili spremenjeni in nato posodobi samo tiste atribute v podatkovni bazi. Na koncu še nastavi trenutno na prvotno vrednost in stanje na nespremenjen. S tem načinom je zagotovljen zelo učinkovit nadzor nad spremembami atributov in minimalnimi popravki v podatkovni bazi. Tudi pri dodajanju novih objektov je postopek podoben, le da se tukaj objekt, ki predstavlja stanje, ustvari komaj, ko objekt označimo za vstavljanje s klicem metode AddToImeEntitete. Pri tem je za vsako entiteto svoja metoda v razredu ObjectContext. V primeru 3.22primer 3.22 je to metoda AddToDepartment. Department d = new Department(); d.name = "Nov oddelek"; d.modifieddate = DateTime.Now; d.groupname = "";
Zagotavljanje trajnosti objektov v ogrodju.net Stran 57 awentities.addtodepartment(d); awentities.savechanges(); d.name = "Drug oddelek"; awentities.savechanges(); awentities.deleteobject(d); awentities.savechanges(); Primer 3.22 Posodabljanje, vstavljanje in brisanje v ogrodju ADO.NET Entity Framework Za brisanje entitet poskrbi metoda DeleteObject, ki kot parameter sprejme poljubno entiteto in ji nastavi stanje na izbrisan. Treba je poudariti, da tudi ogrodje Entity Framework uporablja vzorec enota dela, ki beleži vse spremembe, in jih izvrši komaj ob klicu metode SaveChanges.
Zagotavljanje trajnosti objektov v ogrodju.net Stran 58 4 PRIMERJAVA OGRODIJ V prejšnjem poglavju smo predstavili tri ogrodja za objektno relacijsko preslikavo. V nadaljevanju sledi klasifikacija primerjalnih karakteristik, kjer bomo opisali uporabljene kriterije. V zadnjem delu bomo izvedli samo primerjavo in podali analizo rezultatov. 4.1 Klasifikacija primerjalnih kriterijev Izbor primerjalnih karakteristik je zelo pomemben. V danem primeru smo se odločili, da se ne bomo osredotočili samo na kvantitativne karakteristike, kot so hitrost in učinkovitost porabe pomnilnika, ampak bomo izvedli tudi kvalitativno primerjavo funkcionalnosti. V naslednjih podpoglavjih bomo opisali 12 primerjalnih karakteristik, za katere menimo, da so pomembne pri izbiri ustreznega ogrodja. Kriterijev nismo združevali v skupine, lahko pa podamo vrstni red, v katerem si bodo sledili. Na začetku bomo opisali kriterije, povezane z uporabo ogrodja, za tem bo sledil opis kriterijev po funkcionalnostih in na koncu bomo podali še kvantitativne karakteristike, katerih vrednosti bomo pridobili z meritvami. 4.1.1 Grafična in pomožna orodja V času razvojnih okolij so postala grafična orodja nepogrešljiv sestavni del razvoja informacijskih sistemov. Predvsem v ogrodju.net, kjer je razvoj že od njegovih prvih verzij tesno povezan z razvojnim okoljem Visual Studio. Tako od dobrega ogrodja pričakujemo grafično orodje, ki omogoča urejanje preslikave. Pogosto se načrtovanja lotimo od spodaj navzgor, kjer izhajamo iz obstoječe podatkovne baze. V tem primeru pričakujemo od ogrodja čarovnika ali orodje, ki omogoča generiranje razredov in ustrezne preslikave. 4.1.2 Podpora dedovanju in polimorfizmu Dedovanje je prvina objektno orientiranih programskih jezikov. A ker relacijske podatkovne baze ne podpirajo dedovanja, so se uveljavili trije načini, kako preslikamo
Zagotavljanje trajnosti objektov v ogrodju.net Stran 59 hierarhijo razredov v relacijske tabele. Podrobnejši opis preslikave dedovanja smo podali v poglavju 2.5.4. Če povzamemo, so ti načini: ena tabela za vse razrede, tabela na konkreten razred in tabela na razred. Od kakovostnega ogrodja pričakujemo podporo za vse tri načine razreševanja generalizacije. 4.1.3 Podpora različnim sistemom za upravljanje s podatkovno bazo [34] navaja, da je trenutno na tržišču več kot 60 sistemov za upravljanje s podatkovno bazo (SUPB). Čeprav jih ima le nekaj prevladujoč tržni delež, je pomembno, da nudijo ogrodja podporo za čim večje število SUPB. S tem omogočajo razvoj novih informacijskih sistemov, ki temeljijo na starejših podatkovnih bazah. Nerealno je pričakovati, da bo ogrodje podpiralo vse sisteme za upravljanje s podatkovno bazo. Cilj tega kriterija ni ovrednotiti število podprtih SUPB, ampak želimo preučiti arhitekturno zasnovo ogrodja, ki mora omogočati vključitev različnih sistemov za upravljanje s podatkovno bazo. 4.1.4 Kriteriji»Persistence Ignorance«V poglavju 2.6 smo poudarili, da želimo, da je domenski model čim bolj neodvisen od izbranega ogrodja za ORM. V ta namen smo navedli 7 kriterijev, ki jih v [2] avtor označuje kot»persistence Ignorance«. Ti kriteriji so: dedovanje od specifičnega nadrazreda, izdelava primerkov objektov samo s tovarniško metodo, uporaba posebnih podatkovnih tipov, kot so zbirke, implementirati predpisan vmesnik, predpisati specifičen konstruktor, predpisati obvezne specifične atribute in prepovedana ali obvezna uporaba določenih konstruktov.
Zagotavljanje trajnosti objektov v ogrodju.net Stran 60 Smiselno se nam je zdelo vključiti te kriterije v primerjavo, saj po našem mnenju uspešno naslavljajo problematiko močne sklopljenosti med domenskim modelom in ogrodjem. Kot smo že nakazali, nobeno ogrodje v popolnosti ne zagotavlja neodvisnosti, kajti popolna neodvisnost zahteva prevelike režijske stroške in ne ponuja funkcionalnosti, ki jo nujno potrebujemo. 4.1.5 Dinamične poizvedbe Načini, kako pridobivati podatke, so različni. Večino smo jih že prikazali v opisu posameznih ogrodij, a ta kriterij še vedno ostaja, saj želimo prikazati osnovne razlike med posameznimi implementacijami. Zelo pomembno je, kako so poizvedbe zapisane in, ali imamo pri teh podporo prevajalnika. 4.1.6 Sprotno nalaganje in nalaganje na zahtevo Nalaganje na zahtevo je lastnost ogrodja, da naloži samo zahtevan objekt, ne pa tudi objektov, s katerimi ima ta relacije. Te lahko še vedno naložimo, kadar jih potrebujemo. S tem zagotovimo boljšo izrabo pomnilnika, manj prometa med odjemalcem in podatkovnim strežnikom ter manjšo obremenitev podatkovnega strežnika. Vendar tak način ni vedno zaželen. Za lažje razumevanje naj navedemo primer, s katerim se srečujemo pri razvoju informacijskih sistemov. Pri dostopu do osebnih podatkov se srečujemo z normalizacijo podatkov. Tako imamo podatke o osebi shranjene v eni tabeli, naslov pa v drugi. V takem primeru bi potrebovali dva dostopa do podatkovne baze, da pridobimo konceptualno en podatek. Zaradi tega želimo nastavitev, ki omogoča, da se podatki naložijo hkrati. Tako dobimo vse potrebne podatke v enem samem dostopu do podatkovne baze. V tem kriteriju bomo preverili, kako ogrodja omogočajo sprotno in nalaganje na zahtevo. Pri tem bomo videli, ali se te nastavitve lahko shranijo v preslikavo ali jih je potrebno navesti ob izvedbi preslikave.
Zagotavljanje trajnosti objektov v ogrodju.net Stran 61 4.1.7 Shranjene procedure Shranjene procedure so že dolgo uveljavljene v podatkovnih bazah. Omogočajo kompleksno obdelavo podatkov, za izvedbo katerih potrebujemo več operacij. Za zagotovitev neprekinjenega izvajanja teh operacij so bile razvite transakcije. Navkljub njihovi razširjenosti in pogostosti uporabe jih do sedaj še nismo omenili. Razlog za to je, da so ogrodja sposobna generirati SQL-poizvedbe in ukaze. S tem odpade zahteva po uporabi shranjenih procedur. Vendar pogosto ni tako, saj se shranjene procedure pogosto uporabljajo za varnostno kritične dele, kot je avtorizacija in validacija. V takih primerih želimo, da ogrodje omogoča uporabo shranjenih procedur. Znotraj tega kriterija bomo pogledali, ali sploh, in če da, na kakšen način ogrodja podpirajo uporabo shranjenih procedur. Preverili bomo tudi možnost, da nadomestimo posamezne funkcije, kot so vstavljanje, brisanje in posodabljanje, z uporabo shranjenih procedur. 4.1.8 Transakcije Tudi transakcije so lastnost podatkovnih baz, ki se jih do sedaj še nismo dotaknili. Sistemi za upravljanje s podatkovno bazo zagotavljajo štiri lastnosti transakcij, ki jih v literaturi zasledimo pod akronimom ACID, kar pomeni atomarnost (angl.»atomicity«), konsistentnost (angl.»consistency«), izolacijo (angl.»isolation«) in trajnost (angl.»durability«). Atomarnost določa, da bodo pri nepričakovano prekinjenem procesu transakcije razveljavljene vse operacije, ki sestavljajo transakcijo. Transakcija spremeni stanje podatkovne baze iz enega veljavnega stanja v drugo, kar zagotavlja konsistenco. Izolacija pomeni, da je rezultat izvedbe transakcije prikrit, dokler se ta ne izvede do konca. Učinki transakcije so trajni, reverzibilni in se nikoli ne izgubijo, kar zagotavlja trajnost. Glede na to, da objektno relacijski preslikovalniki delujejo nad podatkovno bazo, bi želeli imeti podporo za izvajanje transakcij. Znotraj tega kriterija bomo preučili, kakšno podporo transakcijam ponujajo ogrodja ORM.
Zagotavljanje trajnosti objektov v ogrodju.net Stran 62 4.1.9 Predpomnjenje Pojem predpomnjenja (angl.»caching«) poznamo iz strojne računalniške opreme. Mikroprocesorji, na primer, imajo predpomnilnik, kjer hranijo zadnji prebran del iz glavnega pomnilnika. Pri tem izkoriščajo lastnost programov, da pogosto zaporedno dostopajo do enake pomnilniške lokacije. Če bi bilo le-to potrebno vsakič prebrati iz pomnilnika in prenesti v procesor, bi bil izkoristek mikroprocesorjev bistveno slabši, kot je sedaj. Podobno kot v zgornjem primeru, lahko opazimo, da nekateri informacijski sistemi v večini prebirajo podatke iz malega števila tabel. Če ob tem še upoštevamo, da imajo te tabele veliko zapisov, lahko kaj hitro ugotovimo podobnosti s prejšnjim primerom. Preverili bomo možnosti, ki jih ponujajo ogrodja ORM, da bi hranili objekte v pomnilniku, ki bi služil kot predpomnilnik. Vendar ima ta pristop tudi pomanjkljivost, ki se pojavi, če več aplikacij dostopa do iste podatkovne baze. V takem primeru ne moremo zagotoviti, da je objekt, ki se nahaja v predpomnilniku, še konsistenten s podatkovno bazo. Zato je v teh primerih uporaba predpomnilnika odsvetovana. 4.1.10 Zaklepanje Pri dostopanju do podatkov v podatkovni bazi se srečujemo s problemom konsistence podatkov. Postavlja se vprašanje, ali so podatki, ki smo jih prebrali iz podatkovne baze, še vedno aktualni? Skozi zgodovino sta se uveljavila dva načina, kako reševati problem konsistence podatkov. To sta pesimistično in optimistično zaklepanje. Pri pesimističnem zaklepanju (angl.»pessimistic Concurrency«) fizično zaklenemo zapis v tabeli. Vsako povpraševanje, ki bi želelo prebrati vsebino, medtem ko je zapis zaklenjen, mora počakati, dokler se zapora ne sprosti.[35] Tak način zaklepanja uporabljajo transakcije, pri katerih so zapisi, nad katerimi operirajo, zaklenjene, dokler se transakcija izvaja. Nasprotje tega je optimistično zaklepanje (angl.»optimistic Concurrency«). V tem načinu se zapis ne zaklene, zato moramo sami ugotavljati nekonsistentnost podatkov. Pogosto se
Zagotavljanje trajnosti objektov v ogrodju.net Stran 63 za to uporabljajo posebni atributi, kot so zaporedna številka, ki se poveča ob vsakem popravku, datum zadnje spremembe ali časovna značka (angl.»timestamp«).[35] Prednost tega načina je, da omogočamo dostop do celotne vsebine tabele, kljub temu da urejamo posamezen zapis. Na drugi strani moramo izpostaviti tudi slabost, ki jo ta način prinaša, kadar pride do konflikta. V tem primeru se proži izjema, ki jo morajo razvijalci ustrezno razrešiti. 4.1.11 Metrike programske kode Razvijalci že od nekdaj merijo programsko kodo. Zaradi tega so se skozi čas razvile metrike, s pomočjo katerih ugotavljamo kakovost programske kode. Razloge, zakaj smo se odločili, da uvedemo metrike kot primerjalni kriterij, najdemo v tem, da ogrodji LINQ to SQL in ADO.NET Entity Framework generirata lastne razrede. S pomočjo metrik programske kode želimo izmeriti kvaliteto in obseg te kode. Za primerjavo bodo služili razredi, ki jih uporablja ogrodje NHibernate. Za analizo smo izbrali naslednje štiri metrike: število vrstic kode, sklopljenost razredov, ciklomatično kompleksnost in indeks vzdrževalnosti. Število vrstic kode Za ugotovitev velikosti se lahko uporabljajo preproste metrike, kot je število vrstic kode (angl.»lines of Code«). To je zagotovo najstarejša in najbolj preprosta metrika. Rezultat metrike je število vrstic, ki poda velikost. Pri tem je pomembno, katere vrstice upoštevamo. Ogrodje za analizo programske kode znotraj Visual Studia 2008 Team System upošteva vse vrstice razen komentarjev, deklaracij spremenljivk, metod in imenskih področij. [37] Sklopljenost razredov Sklopljenost je merilo relativne neodvisnosti modulov oziroma komponent. V tem primeru merimo sklopljenost razredov (angl.»class Coupling«). Metrika za vsak razred izračuna
Zagotavljanje trajnosti objektov v ogrodju.net Stran 64 število z njim povezanih razredov. Ta številka ne vključuje primitivnih tipov ogrodja.net in razreda object. Visoka sklopljenost ima za posledico nizko ponovno uporabo, saj so razredi močno vezani na kontekst in jih je težko uporabiti v drugačnem kontekstu. Poleg tega se, veliko število gosto med sabo povezanih razredov, odraža v nepreglednosti in težko razumevajoči kodi. To je pogosto posledica slabega načrtovanja, kjer niso ustrezno definirane odgovornosti razredov.[36] Ciklomatična kompleksnost Ciklomatična kompleksnost (angl.»cyclomatic Complexity«) je bila prvič predstavljena leta 1976. [36] Njena naloga je ovrednotiti težavnost testiranja in vzdrževanja programske kode. To zagotavlja s štetjem vseh možnih vejitev. Metrika poveča število ob vsakem pogoju if ali switch ter zankah do, while, for in foreach. V praksi se metrika uporablja za določitev števila testov, da zagotovimo polno pokritost kode.[36] V našem primeru bo služila, kot indikator kompleksnosti generirane programske kode. Indeks vzdrževalnosti Zadnja metrika, ki jo bomo uporabili, se imenuje indeks vzdrževalnosti (angl.»maintainability indeks«). Indeks ne meri posamezne značilnosti programske kode, ampak je sestavljen iz števila vrstic kode, ciklomatične kompleksnosti in Halsteadove metrike. Raziskave so pokazale povezanost indeksa in truda, potrebnega za vzdrževanje. Indeks vzdrževalnosti je dober indikator, kdaj zamenjati star sistem, ali kdaj je potrebno premisliti načrtovanje novega. [36] Vrednosti indeksa vzdrževalnosti so omejene med 0 in 100. Pri tem vrednost med 20 in 100 pomeni odlično vzdrževalnost. Vrednost med 10 in vključno 19 pomeni srednje dobro vzdrževalnost. Če pade indeks pod 10, je to znak kompleksne kode, ki jo je zelo težko vzdrževati.[37]
Zagotavljanje trajnosti objektov v ogrodju.net Stran 65 4.1.12 Učinkovitost delovanja Za zadnji kriterij smo se odločili primerjati učinkovitost delovanja ogrodij. Pri tem se bomo osredotočili na hitrost povpraševanja in izvedbe CRUD-operacij ter učinkovitost porabe sistemskih sredstev, kot sta procesor in pomnilnik. Kratica CRUD pomeni zaporedje operacij ustvarjanja (angl.»create«), prebiranja (angl.»read«), posodabljanja (angl.»update«) in brisanja (angl.»delete«). Ta akronim pogosto najdemo v literaturi za opis najpogostejših operacij, ki jih izvaja informacijski sistem. Za potrebe tega kriterija bomo izdelali aplikacijo, s katero bomo izmerili potreben čas za izvajanje povpraševanj in CRUD-operacij. Le-te bomo izvedli v več ciklusih, da zagotovimo zadostno podlago za analizo rezultatov in izključimo odstopanja, ki bi se lahko pojavila v meritvah. Za pridobitev realno primerljivih rezultatov smo se odločili, da bomo uporabili podatkovno bazo AdwentureWorks. To je demonstracijska podatkovna baza podatkovnega strežnika SQL Server 2005. Nad to podatkovno bazo bomo izvedli več povpraševanj. Najprej bomo preizkusili enostavno povpraševanje nad eno entiteto. Le-to bomo nadgradili v drugem preizkusu, kjer bomo ustvarili bolj kompleksno poizvedbo, ki bo vključevala projekcijo, združevanje tabel, agregatne funkcije, grupiranje in sortiranje. Poleg teh poizvedb želimo prikazati še nalaganje na zahtevo in njegove negativne posledice ob napačni uporabi. Nazadnje bomo preizkusili še učinkovitost izvedbe CRUD operacij in primerjali porabo pomnilnika in izkoriščenost procesorja. 4.2 Analiza 4.2.1 Grafična in pomožna orodja Pri primerjavi ogrodij smo ugotovili, da samo Microsoftovi ogrodji ponujata grafična orodja. To je velika pomanjkljivost ogrodja NHibernate, kajti že v danem primeru, kjer smo v preslikavo vključili 67 razredov, se je pokazala nujnost uporabe grafičnega orodja. Žal tudi na internetu nismo našli orodja, ki bi omogočalo vizualno predstavitev hbmdatotek. Največ pomoči, ki jo lahko pričakujemo, je IntelliSense podpora in validacija hbm-datotek.
Zagotavljanje trajnosti objektov v ogrodju.net Stran 66 Razlog, zakaj tako odločno vodita Microsoftovi ogrodji, lahko izpeljemo iz povezanosti ogrodja.net in razvojnega okolja Visual Studio. LINQ to SQL nudi grafični vmesnik za urejanje datotek dbml, ki služijo kot vhod v generiranje razredov. Tudi drugo orodje ponuja grafično orodje ADO.NET Entity Data Model Designer ali krajše EDM Designer. Obe orodji sta tesno integrirani v razvojno okolje Visual Studio 2008 in ponujata nazoren pregled nad entitetami in relacijami med njimi. Medtem ko je grafično orodje ogrodja LINQ to SQL omejeno na spreminjanje imen atributov in preslikave, omogoča EDM Designer izvedbo kompleksnejših preslikav in relacij. Zaradi kompleksnosti shem EDM je uporaba grafičnega orodja neizbežna. Pri tem je potrebno poudariti, da grafično orodje niti ne podpira vseh lastnosti entitetnega podatkovnega modela. Zato je v nekaterih primerih potrebno ročno spreminjanje edmxdatoteke. Poleg grafičnih ponujata ogrodji še orodja, ki se zaganjajo iz ukazne vrstice. To sta že opisana SqlMetal in EdmGen. Ti omogočata izdelavo razredov iz modela, oziroma modela iz podatkovne baze. 4.2.2 Podpora dedovanju in polimorfizmu Pri podpori dedovanja se pokažejo slabosti ogrodja LINQ to SQL. Ta namreč podpira samo eno strategijo preslikave hierarhije razredov v podatkovno bazo, to je ena tabela za vse razrede. Ta strategija uporablja ločilni atribut, na podlagi česar se odloča, v kateri razred se zapis preslika. Drugi ogrodji se boljše izkažeta, saj podpirata vse tri načine razreševanja dedovanja. Za dosego tega uporablja NHibernate elemente subclass, union-subclass in joinedsubclass. Element subclass določa strategijo ena tabela za vse razrede, pri čemer moramo v nadrazredu definirati discriminator, ki določa ločilni atribut. Strategijo tabela na konkreten razred določa union-subclass, joined-subclass pa tabelo na razred. Kot že omenjeno, tudi ADO.NET Entity Framework omogoča uporabo vse treh strategij. Le-te se določajo z orodjem EDM Designer. Zaradi kompleksnih posledic, ki jih ima vnos
Zagotavljanje trajnosti objektov v ogrodju.net Stran 67 dedovanja v shemo entitetnega podatkovnega modela, le teh tukaj ne bomo podrobneje opisovali. Natančen opis in razlago lahko najdemo v [12] in [28]. 4.2.3 Podpora različnim sistemom za upravljanje s podatkovno bazo Podpora sistemom za upravljanje s podatkovno bazo je povezana z arhitekturno zasnovo ogrodij. Pri tem LINQ to SQL podpira samo podatkovni strežnik Microsoft SQL Server od različice 2000 naprej. Na drugi strani ogrodje NHibernate za dostop do podatkov gradi na ADO.NET podatkovnih ponudnikih. Ti omogočajo uporabo ponudnikov za podatkovne baze, kot so Microsoft SQL Server, Oracle, IBM DB2, MySQL, ODBC in drugih, ki jih poznamo iz klasičnega razvoja z ADO.NET. Tudi ogrodje ADO.NET Entity Framework gradi na enakih ponudnikih, vendar morajo ti dodatno podpreti ogrodje. Temu Microsoft pravi Entity Framework omogočeni ponudniki (angl.»entity Framework Enabled Data Provider«). Celoten seznam ponudnikov je na voljo na [38]. Pri tem moramo poudariti, da Microsoft ne načrtuje podpore za standard Open Database Connectivity (ODBC) ter posledično tudi ne podatkovne baze Access. 4.2.4 Kriteriji»Persistence Ignorance«Za ocenjevanje kriterijev PI smo izbrali tri vrednosti. Ogrodje lahko popolnoma, sploh ne, ali le delno izpolnjuje kriterije. V nekaterih primerih smo ugotovili, da ogrodja težko v celoti izpolnijo kriterij, a ne moremo reči, da ga sploh ne. Zato smo se odločili, da v takih primerih podelimo oceno delno izpolnjuje. Sedaj bomo na kratko predstavili in komentirali rezultate, ki so razvidni iz tabele 4.1. Najprej smo ovrednotili ogrodje LINQ to SQL, ki skoraj v celoti izpolnjuje vse kriterije. Ne zahteva dedovanja od nadrazreda ali izdelave primerkov preko tovarniške metode, ne dopušča pa uporabe standardnih zbirk. Če želimo uporabiti nalaganje na zahtevo, orodje zahteva uporabo tipov EntityRef za relacije mnogo proti ena in EntitySet za relacije ena proti mnogo in mnogo proti mnogo. Pri tehnologiji LINQ smo prisiljeni uporabljati vmesnika IEnumerable<T> in IQuerable<T>. Poleg tega ogrodje privzeto izdela razrede, ki implementirajo vmesnika INotifyPropertyChanging in INotifyPropertyChanged. Vendar ta vmesnika nista pogojena z ogrodjem, služita
Zagotavljanje trajnosti objektov v ogrodju.net Stran 68 samo lažji dopolnitvi delnih razredov. Zato smo podelili le oceno delno izpolnjuje. LINQ to SQL predpisuje samo privzet konstruktor, zaradi tega tudi samo ocena delno izpolnjuje. Ogrodje ne predpisuje ali prepoveduje uporabe specifičnih atributov, vedeti moramo le, da ogrodje za namen preslikave potrebuje anotacije. Te so potrebne tudi če uporabimo eksterno definirano XML datoteko, zato zadnjega pogoja ne izpolnjuje. Na drugi strani imamo NHibernate, ki izhaja iz javanske različice, za katero je značilen visok nivo»persistence Ignorance«. In tako je tudi pri ogrodju NHibernate. V večini NHibernate izpolnjuje vse kriterije, a vendar ima nekaj omejitev. Najprej bi omenili potrebo po privzetem konstruktorju. Nadalje ni dovoljena uporaba readonly atributov in predpisana je uporaba ključne besede virtual na atributih. Zaradi tega si je ogrodje prislužilo skoraj najvišjo možno oceno. Izpostaviti moramo le dva kriterija, kjer je ogrodje prejelo oceno delno izpolnjuje. Kot smo ugotovili do sedaj, LINQ to SQL dobro izpolnjuje kriterije, sedaj bomo pogledali rezultate naprednejšega od obeh Microsoftovih ogrodij. Entity Framework privzeto deduje od razreda EntityObject, a le-ta za preslikavo ni nujno potreben, saj so razvijalci ogrodja omogočili preslikavo samo z uporabo vmesnikov. Le-to so poimenovali princip IPOCO, kar pomeni POCO z uporabo vmesnikov. Zaradi tega si je ogrodje v četrtem kriteriju zaslužilo negativno oceno. Navkljub temu da ogrodje eksplicitno ne zahteva uporabe razreda EntityObject, si je vendarle prislužilo le vmesno oceno, saj menimo, da se bo večinoma uporabljala rešitev z dedovanjem od razreda EntityObject. Poleg naštetega ogrodje še zahteva shranjevanje vrednost EntityKey objekta in dopolnjen dostop do atributov s kodo, potrebno za vodenje sprememb. Zaradi teh lastnosti se je ogrodje odrezalo slabše od pričakovanj in prejelo skupno najslabšo oceno. Tabela 4.1 Kriteriji»Persistence Ignorance«Kriterij Dedovanje od specifičnega nadrazreda Izdelava primerkov objektov samo s tovarniško metodo Uporaba posebnih podatkovnih tipov Implementirati predpisan vmesnik Predpisati specifičen konstruktor Predpisati obvezne specifične atribute LINQ to SQL ADO.NET Entity Fr. NHibernate
Zagotavljanje trajnosti objektov v ogrodju.net Stran 69 Prepovedana ali obvezna uporaba določenih konstruktov - Izpolnjuje kriterij - Delno izpolnjuje kriterij - Ne izpolnjuje kriterija Na podlagi zgornje tabele vidimo, da obstajajo bistvene razlike med ogrodji. Kot najboljše se je izkazalo ogrodje NHibernate, temu sledi LINQ to SQL, razočaral je ADO.NET Entity Framework. Vendar če ob tem upoštevamo zrelost ogrodij, to ni več tako presenetljivo. NHibernate je bilo leta 2005 prvo ogrodje za objektno relacijsko preslikavo v ogrodju.net. Temu je šele konec leta 2007 sledilo ogrodje LINQ to SQL, julija 2008 je izšel ADO.NET Entity Framework. Na podlagi teh podatkov je razumljivo, zakaj je NHibernate uspel doseči tako visok nivo»persistence Ignorance«. 4.2.5 Dinamične poizvedbe Za razumevanje različnih načinov poizvedb je potrebno poznati zgodovino razvoja ORMogrodij. Ogrodje NHibernate je bilo prevedeno iz javanske različice Hibernate. Le-ta je vsebovala povpraševalni jezik HQL, ki ga je prevzel tudi NHibernate. Ta jezik se močno zgleduje po jeziku SQL in skoraj v celoti uporablja poznano sintakso. SQL je namreč najbolj uveljavljen in standardiziran povpraševalni jezik, ki se razvija že od leta 1986. Tako je razumljivo, zakaj so se razvijalci zgledovali po tem jeziku. Tako kot NHibernate, ponuja tudi Entity Framework svoj povpraševalni jezik Entity SQL, ki tudi posnema jezik SQL. Vendar imajo vsi ti jeziki skupno slabost. Zapisani so namreč v besedilu kot niz znakov in zato niso v dosegu prevajalnika. Zaradi tega so pri Microsoftu začeli razvijati povpraševanja, ki bi bila napisana v programski kodi. Nastal je LINQ, ki je prinesel novost v programski svet, kot je še ni bilo. Kajti LINQ omogoča, da pišemo poizvedbe nad strogo tipiziranimi objekti s polno podporo IntelliSense in prevajalnika. Treba je povedati, da sta se ogrodji LINQ to SQL in ADO.NET Entity Framework razvijali neodvisno. Šele s pojavom tehnologije LINQ so ADO.NET razvijalci videli potencial in razvili različico LINQ to Entities. Zaradi razširljivosti tehnologije LINQ se pojavljajo vedno nova področja uporabe. Tako je bil tudi razvit dodatek LINQ to NHibernate, ki omogoča izvajanje povpraševanj nad NHibernate entitetami.
Zagotavljanje trajnosti objektov v ogrodju.net Stran 70 Kot vidimo, so komaj z uvedbo tehnologije LINQ poizvedbe prišle pod nadzor prevajalnika. Žal smo pri LINQ-poizvedbah trenutno še omejeni na samo nekaj standardnih povpraševalnih operatorjev, a kljub temu je to velik napredek od poizvedb, zapisanih v nizu. 4.2.6 Sprotno nalaganje in nalaganje na zahtevo Nalaganje na zahtevo je privzet način nalaganja relacij v vseh primerjanih ogrodij. Medtem ko je to v ogrodjih LINQ to SQL in NHibernate podprto implicitno, je potrebno v ogrodju Entity Framework to eksplicitno zahtevati s klicem metode Load. Zaradi tega postane koda hitro nepregledna, saj moramo vsakič preverjati, ali je relacija naložena, in jo naložiti, če ni. Seveda je možno že v času poizvedbe naložiti ogrodju, da naloži potrebne objekte, a nas to pripelje do sprotnega nalaganja. ADO.NET Entity Framework omogoča sprotno nalaganje relacij z uporabo metode Include, nad razredom ObjectQuery. Tudi LINQ to SQL ima podporo za sprotno nalaganje, vendar je ta implementirana na drugačen način. Da določimo, katere relacije naj se naložijo hkrati z objektom, moramo ustvariti objekt tipa DataLoadOptions in v metodi LoadWith<T> določiti relacijo, ki naj se naloži. Te nastavitve podamo razredu DataContext, ki poskrbi, da se bodo relacije naložile ob istem času kot objekt. Pri ogrodju NHibernate je postopek preprostejši. Za potrebe sprotnega nalaganja je treba v XML-datoteki, ki opisuje preslikavo, nastaviti atribut relacije lazy na false. Vendar ima to tudi slabo stran, saj se relacije naložijo tudi takrat, kadar jih ne potrebujemo. V ostalih ogrodjih se namreč ta lastnost nastavi v času izvajanja, za vsako povpraševanje posebej. 4.2.7 Shranjene procedure Vsa tri ogrodja podpirajo shranjene procedure, vendar vsako na svoj način. Dodajanje shranjenih procedur v ogrodju LINQ to SQL poteka preko grafičnega orodja. Pri tem se za vse shranjene procedure izdelajo ustrezne metode v razredu DataContext. Ogrodje omogoča uporabo tako shranjenih procedur, ki vračajo skalarne vrednost, kakor tudi tistih, ki vračajo celotne zapise. Od tega je odvisno, ali se rezultat procedure preslika v entiteto
Zagotavljanje trajnosti objektov v ogrodju.net Stran 71 ali se izdela nov razred, katerega atributi predstavljajo izhodne vrednosti shranjene procedure. V ogrodju NHibernate se shranjene procedure dodajajo v datotekah hbm. Pri tem smo omejeni samo na procedure, ki vračajo celotne zapise. Shranjeno proceduro definiramo v sql-query elementu, kjer podamo ukaz za proženje in ime procedure ter seznam parametrov. Iz kode dostopamo do shranjene procedure preko sejnega objekta in metode GetNamedQuery. Žal NHibernate ne omogoča tako intuitivnega načina uporabe, kot to ponuja LINQ to SQL. Tudi Entity Framework v tej točki na zaostaja za ostalima. Polno podporo ponuja tako shranjenim proceduram, ki vračajo skalarne vrednosti, kot tudi tistim, ki vračajo entitete. Procedure se preprosto dodajajo preko grafičnega orodja EDM Designer. Za vsako shranjeno proceduro, ki jo dodamo, se izdela ustrezna metoda v razredu ObjectContext. Glede zamenjave ukazov za vstavljanje, brisanje in posodabljanje entitet s shranjenimi procedurami, lahko povemo, da jih vsa preizkušena ogrodja podpirajo v enaki meri. 4.2.8 Transakcije Vsa ogrodja podpirajo transakcije, s tem da ogrodji LINQ to SQL in ADO.NET Entity Framework podpirata tako eksplicitno, kot tudi implicitno uporabo transakcij. Eksplicitna uporaba transakcije pomeni, da uporabnik v programski kodi zahteva uporabo transakcije. Na drugi strani imamo implicitno uporabo, kjer je ogrodje samo zmožno ugotoviti, kdaj je potrebna uporaba transakcije. Za implicitno uporabo transakcij skrbi vzorec enota dela, ki ob večjem številu vnosov, izbrisov ali posodobitev avtomatsko uporabi transakcijo. Ogrodje NHibernate v tej točki malce zaostaja, saj je potrebno vsako uporabo transakcije eksplicitno definirati. Treba je še poudariti, da vsa tri ogrodja uporabljajo transakcije iz ogrodja ADO.NET. 4.2.9 Predpomnjenje Uporaba predpomnilnika je šibka točka Microsoftovih ogrodij, saj nobeno od ogrodij tega ne podpira. Le ogrodje NHibernate ponuja možnost predpomnjenja objektov. Za
Zagotavljanje trajnosti objektov v ogrodju.net Stran 72 razumevanja predpomnjenja kakor ga uporablja NHibernate, moramo poznati arhitekturno zasnovo ogrodja. Le-ta nudi dva nivoja predpomnilnika. Prvonivojski predpomnilnik služi sejnemu objektu in vzorcu slovar identitet za shranjevanje referenc. Ta se ustvari za vsako sejo posebej, je popolnoma neodvisen od drugih sej in se ob njenem zaprtju uniči. Drugonivojski predpomnilnik je tisti, do katerega imamo dostop razvijalci. Za vklop je potrebno v konfiguracijsko datoteko vnesti ustrezne informacije o razredu, ki upravlja predpomnjenje. NHibernate ne ponuja svojih ponudnikov za upravljanje predpomnilnika, lahko pa uporabimo predpomnilnik iz ogrodja ASP.NET ali katerega izmed odprtokodnih ponudnikov. Ne glede na to, za katerega ponudnika se odločimo, je upravljanje s predpomnilnikom enako, saj je vsa funkcionalnost dostopna preko vmesnika ICache. Potrebno je izpostaviti še delovanje drugonivojskega predpomnilnika. Ta namreč ne hrani celotnega grafa objektov in njihovih povezav, ampak si ga lahko predstavljamo kot seznam zgoščenih tabel, ki vsebujejo vrednosti atributov objekta. Pri izvedbi povpraševanj, le-te najprej preverijo, ali objekt obstaja v predpomnilniku. Če obstaja zapis v predpomnilniku, se iz zgoščene tabele rekonstruira objekt. V nasprotnem primeru se izvede povpraševanje nad podatkovno bazo. 4.2.10 Zaklepanje Pri primerjavi smo ugotovili, da vsa tri ogrodja uporabljajo optimistično zaklepanje. To pomeni, da se pri vsakem shranjevanju sprememb preverja konsistenca podatkov s podatkovno bazo. Vsako ogrodje je implementirano tako, da proži izjemo, če ugotovi nekonsistenco podatkov. Medtem ko ogrodji LINQ to SQL in ADO.NET Entity Framework ne podpirata eksplicitnega pesimističnega zaklepanja, pa ogrodje NHibernate to omogoča. Pri tem je treba poudariti, da se ne zaklepajo objekti, ampak n-terice, ki jih ti objekti predstavljajo. NHibernate za potrebe zaklepanja ponuja metodo Lock, definirano v vmesniku ISession. Le-ta lahko zaklene zapis z uporabo različnih mehanizmov, kot so Write, Upgrade in Read. S tem ukazom si zagotovimo ekskluzivni dostop do zapisa, ki se sprosti komaj ob zapisu spremembe v podatkovno bazo.
Zagotavljanje trajnosti objektov v ogrodju.net Stran 73 4.2.11 Metrike programske kode Metrike programske kode, ki smo jih podrobneje opisali v prejšnjem poglavju, smo izračunali s pomočjo orodja, vgrajenega v razvojno okolje Visual Studio 2008 Team System. Ta metrike ne izračunava na podlagi izvorne kode, ampak uporablja vmesno kodo (angl.»intermediate Language«), ki nastane po prevajanju. Tabela 4.2 povzema rezultate, ki smo jih dobili na podlagi izvedbe metrik. Knjižnice, nad katerimi smo jih izvedli, so enake, kot jih uporabljamo pri meritvah učinkovitosti ogrodij, opisanih v naslednjem poglavju. Sedaj povejmo le, da so razredi izdelani na podlagi entitet podatkovne baze AdwentureWorks. Pri izdelavi smo uporabili ustrezna grafična orodja, oziroma v primeru ogrodja NHibernate smo uporabili ogrodje MyGeneration. Pri tem smo uporabili predlogo, ki izdela razred, njegov privzeti konstruktor, zasebne atribute in metode za njihov dostop ter relacije za tuje ključe. Razredi ogrodja NHibernate služijo kot referenčna vrednost domenskega modela, saj ne vsebujejo kode, ki bi jo vsiljevalo ogrodje. Tabela 4.2 Izračunane metrike programske kode Metrika LINQ to SQL ADO.NET Entity Framework NHibernate Število vrstic kode 5376 3166 1311 Sklopljenost razredov 1231 1217 67 Ciklomatična kompleksnost 3144 1879 1334 Indeks vzdrževalnosti 81 85 93 Na podlagi dobljenih rezultatov vidimo, da imata ogrodji LINQ to SQL in Entity Framework večji obseg kode, kot je to pri ogrodju NHibernate. Pri ogrodju LINQ to SQL tega obsega ne moremo izključno pripisati razredu DataContext, saj le-ta vsebuje le 76 vrstic kode. Večino obsega namreč predstavljajo entitete. Pri ogrodju Entity Framework je implementacija boljša, kar ima za posledico manjši obseg kode. Opazen je le povečan obseg kode v razredu ObjectContext, ki ima 267 vrstic. Še večje razlike se pokažejo pri sklopljenosti razredov. Vidimo, da ima NHibernate zelo nizko sklopljenost. To je posledica uporabe šibko tipiziranih vmesnikov, ki jih uporabljamo za relacije ena proti mnogo in mnogo proti mnogo. NHibernate namreč odsvetuje uporabo strogo tipiziranih zbirk. Višja sklopljenost pri ostalih dveh ogrodjih je posledica uporabe strogo tipiziranih relacij, konteksta in sledenja spremembam. Vse te lastnosti samo potrjujejo slabo neodvisnost modela od ogrodja.
Zagotavljanje trajnosti objektov v ogrodju.net Stran 74 Ciklomatična kompleksnost izraža število možnih poti skozi kodo. Pri ogrodjih NHibernate in Entity Framework sta ti vrednosti skoraj izenačeni. Malenkost višja vrednost ogrodja Entity Framework je posledica visoke ciklomatične kompleksnosti razreda ObjectContext. Ta vrednost je dosežena predvsem z odsotnostjo implicitnega nalaganja na zahtevo. Če bi preverjali, ali so relacije naložene, bi bila v entitetnih razredih ta vrednost zagotovo višja, kakor vidimo pri ogrodju LINQ to SQL. Predvsem zaradi tega vidimo izjemno povišanje ciklomatične kompleksnosti v ogrodju LINQ to SQL. Zadnja metrika, ki smo jo uporabili, je indeks vzdrževalnosti. Kot vidimo na podlagi rezultatov, vsa primerjana ogrodja nudijo visok nivo vzdrževalnosti. Zelo dobro se izkaže ogrodje NHibernate, ki ima najvišji indeks. Tak rezultat ni presenetljiv, saj razredi vsebujejo samo konstruktor in atribute. Dober rezultat je doseglo tudi ogrodje ADO.NET Entity Framework, saj skozi vse razrede ponuja visok indeks vzdrževalnosti. V tem kriteriju razočara le ogrodje LINQ to SQL. Pri podrobnejši analizi smo ugotovili, da v nekaterih razredih pade indeks vzdrževalnosti celo pod 70. Čeprav je to še vedno v mejah odlične vzdrževalnosti, ta kaže na slabšo neodvisnost modela od ogrodja. Če povzamemo, ugotovimo, da so metrike dober pokazatelj neodvisnosti modela od ogrodja in nudijo kvantitativno dopolnilo kriterijem»persistence Ignorance«. Iz rezultatov je razvidno, da ogrodji LINQ to SQL in ADO.NET Entity Framework ne ponujata visoke neodvisnosti modela od ogrodja. Seveda so slabši rezultati tudi posledica generiranja razredov na podlagi podatkovnega modela in s tem posledično tudi kode, ki jo uporablja ogrodje. A smo zavestno izbrali ta način, ker predstavlja najpogostejši način uporabe ogrodja. 4.2.12 Učinkovitost delovanja Za potrebe testiranja smo se odločili uporabiti podatkovno bazo AdwentureWorks. To je demonstracijska podatkovna baze za podatkovni strežnik SQL Server 2005 in predstavlja podjetje, ki izdeluje in trži kolesa. Prednost uporabe te podatkovne baze je v tem, da podatkovna shema vsebuje tabele in smiselno med seboj povezane podatke. Po določitvi podatkovnega vira smo izdelali potrebne entitete. Ker ogrodje NHibernate samo ne omogoča uvoza entitet iz tabel, smo uporabili program MyGeneration, ki je z
Zagotavljanje trajnosti objektov v ogrodju.net Stran 75 ustreznimi predlogami sposoben izdelati razrede in potrebne konfiguracijske datoteke.[39] Odločili smo se za predlogo, ki izdela razred, njegov privzeti konstruktor, zasebne atribute in metode za njihov dostop ter relacije za tuje ključe. Po izboru orodij smo izdelali entitetne razrede za vse tabele podatkovne baze AdwentureWorks. Dalje je sledila krajša optimizacija modela in razrešitev relacij mnogo proti mnogo. Nato smo ustvarili preprosto konzolno aplikacijo, v kateri smo definirali vmesnik IBenchmark, ki predpisuje metodo Run in dogodek ReportProgress. Vsi testi implementirajo ta vmesnik, in s pomočjo razreda System.Diagnostics.Stopwatch merijo porabljen čas. S tem smo zagotovili, da lahko izvedemo vse teste preko enotnega vmesnika. Primer razreda, ki implementira ta vmesnik, je prikazan v primeru 4.1. public class LINQtoSQLBenchmark : IBenchmark { System.Diagnostics.Stopwatch sw = new System.Diagnostics.Stopwatch(); #region IBenchmark Members public void Run(int count, object param) { sw.start(); AWDataContext awcontext = new AWDataContext(); ReportProgress(sw.ElapsedMilliseconds, EventArgs.Empty); for (int i = 0; i < count; i++) { List<SalesOrderDetail> sales = (from salesorder in awcontext.salesorderdetails where salesorder.orderqty > param select salesorder).tolist(); } ReportProgress(sw.ElapsedMilliseconds, EventArgs.Empty); } sw.stop(); public event EventHandler ReportProgress; } #endregion Primer 4.1 Primer testa za meritev časovne učinkovitosti V nadaljevanju predstavljeni rezultati temeljijo na povprečni vrednosti meritev, ki smo jih izvedli v več ciklusih na sistemu z naslednjo konfiguracijo: procesor Intel Pentium 4 3.0 HT GHz,
Zagotavljanje trajnosti objektov v ogrodju.net Stran 76 3.0 GByte pomnilnika, podatkovni strežnik Microsoft SQL Server 2008 in operacijski sistem Microsoft Windows Vista SP1. Za referenčne vrednosti smo se odločili uporabiti knjižnice in razrede iz standardnega nabora ADO.NET. Ker se povezujemo s podatkovnim strežnikom Microsoft SQL Sever 2008, se ti razredi nahajajo v imenskem prostoru System.Data.SqlClient. Enostavna poizvedba Najprej smo izvedli meritev hitrosti 100-tih poizvedb nad eno tabelo z omejitvijo, katerih rezultati vračajo približno 30.000 zapisov. Pri tem smo merili čas nalaganja, in čas po vsaki poizvedbi. V tabeli 4.3 navajamo čas nalaganja, trajanje prve in stote poizvedbe ter skupen čas. Te vrednosti so pomembne za razumevanje delovanja ogrodij. Čas nalaganja je čas v katerem izdelamo primerek konteksta oz. seje. Ta je v primeru ogrodja NHibernate daljši, saj je izdelava seje časovno potratna. Razlika med prvo in stoto poizvedbo je posledica uporabe slovarja identitet in notranje optimizacije ogrodij. Pri tem je treba dodati, da pri nobeni meritvi nismo uporabili predpomnilnika. Tabela 4.3 Primerjava hitrosti izvedbe povpraševanja LTS HQL CQ E SQL LTE SQL Čas nalaganja [ms] 140 2.700 2.700 230 230 200 1. izvedba [ms] 2.000 5.700 5.600 3.500 3.500 370 100. izvedba [ms] 240 410 410 930 940 310 Skupen čas [ms] 27.400 49.500 49.500 102.400 104.000 33.800 LTS LINQ to SQL, HQL Hibernate Query Language, CQ Criteria Query, E SQL Entity SQL, LTE LINQ to Entities, SQL SqlClient Kot vidimo iz zgornje tabele, pride do presenetljivega končnega rezultata. Nepričakovano ogrodje LINQ to SQL izvede poizvedbe hitreje, kot referenčna meritev z uporabo standardnih knjižnic. Slika 4.1 prikazuje čas, potreben za izvedbo določenega števila operacij. Pri tem opazimo strogo linearno naraščanje krivulj, kar je posledica neuporabe predpomnilnika. Pri ogrodju NHibernate opazimo daljši čas za izdelavo sejnega objekta, nato pa bolj položno premico.
Zagotavljanje trajnosti objektov v ogrodju.net Stran 77 Slika 4.1 Primerjava hitrosti izvedbe povpraševanja V izvedenem testu je razočaralo ogrodje ADO.NET Entity Framework, saj ga je predzadnje uvrščeno ogrodje NHibernate prehitelo kar za polovico. Pri podrobnejši analizi opazimo, da ne pride do večjih odstopanj med različnimi načini poizvedbe znotraj enega ogrodja. Tako obe povpraševalni metodi v ogrodju NHibernate dosežeta identičen rezultat in tudi pri ogrodju Entity Framework ne pride do večjih razlik med poizvedbami opravljenimi z Entity SQL in LINQ to Entities. Kompleksna poizvedba Za drugo meritev smo se odločili uporabiti kompleksnejšo poizvedbo, ki bo vsebovala projekcijo čez več tabel, grupiranje in sortiranje. Tako smo izdelali poizvedbo, ki pridobi podatke o kupcih, njihovi skupni vrednosti vseh nakupov in vse to uredi v padajočem vrstnem redu glede na skupno vrednost nakupov. Čas nalaganja posameznega ogrodja je v vseh meritvah enak. Zato jih v nadaljevanju več ne navajamo. Tabela 4.4 Primerjava hitrosti izvedbe kompleksnega povpraševanja LTS HQL CQ E SQL LTE EC SQL 1. izvedba [ms] 1.900 750 1.100 430 4.400 3.560 320 100. izvedba [ms] 260 300 680 400 330 330 310 Skupen čas [ms] 28.500 30.600 73.000 44.600 35.000 33.800 32.000 LTS LINQ to SQL, HQL Hibernate Query Language, CQ Criteria Query, E SQL Entity SQL, LTE LINQ to Entities, EC EntityClient, SQL SqlClient
Zagotavljanje trajnosti objektov v ogrodju.net Stran 78 Kot lahko razberemo iz tabele 4.4, se vrednosti bistveno ne razlikujejo od prej. Za razliko poskrbi le ogrodje NHibernate, ki z jezikom HQL prehiti poizvedbe, opravljene s SQL. Tudi ponudnik na nivoju entitete (EntityClient) se ne odreže bistveno bolje od objektnih storitev. Negativno izstopa kriterijsko povpraševanje, saj zasede zadnje mesto. To je zagotovo rezultat slabe podpore združevanju tabel v tem načinu, saj je potrebno za vsako združevanje izdelati nov objekt tipa ICriteria. Nalaganje na zahtevo Kako se obnese sprotno nalaganje, bomo prikazali v naslednji meritvi. Razred Employee ima dvosmerno relacijo na samega sebe, ki predstavlja razmerje nadrejeni podrejeni. Ogrodjem ORM smo naročili, naj to relacijo naložijo sproti, tako da dobimo celotno drevo objektov. Pri tem je treba poudariti, da ogrodje LINQ to SQL ne omogoča sprotnega nalaganja relacij na samega sebe. Zato so v tabeli 4.5 prikazani samo rezultati ogrodij NHibernate in Entity Framework. Tabela 4.5 Primerjava hitrosti nalaganja na zahtevo HQL CQ E SQL LTE 1. izvedba [ms] 3.400 3.400 5.400 5.700 100. izvedba [ms] 410 410 920 1.000 Skupen čas [ms] 50.200 49.900 100.000 102.200 HQL Hibernate Query Language, CQ Criteria Query, E SQL Entity SQL, LTE LINQ to Entities Nalaganje na zahtevo je posebnost ogrodij ORM. Če bi to želeli izvesti z uporabo jezika SQL, bi potrebovali več poizvedb. Poleg tega ne bi bili zmožni doseči primerljivih rezultatov, saj v našem primeru nalagamo relacijo na samega sebe. To ima za posledico nepredvidljivo zaporedje nalaganja objektov v času, ko se gradi drevesna struktura. Zaradi tega smo v tem kriteriju izpustili referenčno vrednost. Vstavljanje, posodabljanje, brisanje Zadnji test, ki smo ga izvedli, je bil namenjen določitvi hitrosti ogrodij pri osnovnih operacijah, kot so vstavljanje, posodabljanje in brisanje objektov. Izdelali smo nov test, kjer ustvarimo primerek razreda ProductReview, ga napolnimo s podatki. Nato ta objekt vstavimo v podatkovno bazo, spremenimo atribut in ponovno shranimo spremembe. Na koncu še izbrišemo zapis iz podatkovne baze. Za določitev povprečne vrednosti smo ta
Zagotavljanje trajnosti objektov v ogrodju.net Stran 79 proces ponovili 10.000 krat. Slika 4.2 prikazuje povprečni čas, ki je potreben za izvedbo opisanih operacij. Slika 4.2 Povprečen čas izvedbe vnosa, posodobitve in izbrisa Kot lahko vidimo, to delo najhitreje opravi ogrodje NHibernate. Ogrodje LINQ to SQL, ki se je do sedaj odlično izkazalo, tu ni doraslo svoji konkurenci. Povprečni čas je kar 600 % počasnejši od najhitrejšega in skoraj 250 % počasnejši od ogrodja ADO.NET Entity Framework. Učinkovitost porabe sistemskih sredstev Razen hitrosti izvedbe poizvedb nas je še zanimalo, kako učinkovito ogrodja uporabljajo sistemska sredstva, kot sta procesor in pomnilnik. Zato smo določili štiri kazalnike, ki omogočajo lažje razumevanje delovanja ogrodij. Ti kazalniki so: izkoristek procesorja, poraba pomnilnika, število naloženih knjižnic in število naloženih razredov. Tabela 4.6 Učinkovitost izrabe procesorja in pomnilnika LTS HQL CQ E SQL LTE SQL Procesor [%] 65,0 93,3 94,2 98,6 98,5 90,5 Pomnilnik [MB] 32,1 60,3 60,8 61,9 64,8 27,4 Št. nal. knjižnic 13 18 18 21 21 9 Št. nal. razredov 73 1.152 1.131 126 126 39 LTS LINQ to SQL, HQL Hibernate Query Language, CQ Criteria Query, E SQL Entity SQL, LTE LINQ to Entities, SQL SqlClient