Vztrajanje podatkov z Java Data Objects, 1. del

"Vse naj bo čim bolj preprosto, a ne bolj preprosto."

Albert Einstein

Potreba po vztrajanju podatkov, ustvarjenih med izvajanjem, je stara toliko kot računalništvo. In potreba po shranjevanju objektno usmerjenih podatkov, ki so se pojavili, ko je objektno usmerjeno programiranje postalo razširjeno. Trenutno večina sodobnih, netrivialnih aplikacij uporablja objektno usmerjeno paradigmo za modeliranje domen aplikacij. V nasprotju s tem je trg baz podatkov bolj razdeljen. Večina sistemov baz podatkov uporablja relacijski model, vendar se objektne shrambe podatkov v mnogih aplikacijah izkažejo za nepogrešljive. Poleg tega imamo tudi starejše sisteme, s katerimi se moramo pogosto povezati.

Ta članek opredeljuje težave, povezane z obstojnostjo podatkov v transakcijskih okoljih vmesne programske opreme, kot je J2EE (Java 2 Platform, Enterprise Edition), in prikazuje, kako Java Data Objects (JDO) rešuje nekatere od teh težav. Ta članek vsebuje pregled in ne podrobne vaje in je napisan z vidika razvijalca aplikacij in ne oblikovalca implementacije JDO.

Preberite celotno serijo o Java Data Objects:

1. del Spoznajte lastnosti idealne obstojnosti
Del 2. Sun JDO proti Castor JDO

Razvijalci, oblikovalci in arhitekti J2EE, ki delajo na sistemih, ki morajo podatke hraniti v relacijskih ali predmetnih bazah podatkov ali drugih nosilcih podatkov, bi morali prebrati ta članek. Predvidevam, da imate osnovno znanje Jave in nekaj poznavanja predmetno-relacijskih vprašanj in terminologije.

Prozorna vztrajnost: Zakaj bi se trudila?

Več kot desetletje neprekinjenih poskusov premostitve objektno usmerjenega izvajanja in vztrajnosti kaže na več pomembnih opažanj (naštetih po pomembnosti):

Odvzemanje podrobnosti o obstojnosti in čist, preprost, objektno usmerjen API za izvajanje shranjevanja podatkov je najpomembnejše. Nočemo obdelovati podrobnosti o obstojnosti in notranjega predstavljanja podatkov v shrambah podatkov, pa naj bodo relacijski, objektni ali kaj drugega. Zakaj bi se morali ukvarjati z nizkostrokovnimi modeli modela shrambe podatkov, kot so vrstice in stolpci, in jih nenehno prevajati naprej in nazaj? Namesto tega se moramo osredotočiti na tisto zapleteno aplikacijo, ki smo jo morali dostaviti do včeraj.
Pri svojih shrambah podatkov želimo uporabiti pristop plug-and-play: uporabiti želimo različne ponudnike / izvedbe, ne da bi spremenili vrstico izvorne kode aplikacije - in morda brez spreminjanja več kot nekaj vrstic v ustrezni konfiguracijski datoteki ( s). Z drugimi besedami, za dostop do podatkov, ki temeljijo na predmetih Java, potrebujemo industrijski standard, ki ima podobno vlogo kot JDBC (Java Database Connectivity) kot industrijski standard za dostop do podatkov, ki temeljijo na SQL.
Pristop plug-and-play želimo uporabiti z različnimi paradigmami baz podatkov - to pomeni, da želimo z relacijske baze podatkov preiti na objektno usmerjeno z minimalnimi spremembami kode aplikacije. Čeprav je to v praksi lepo imeti, ta sposobnost pogosto ni potrebna.
En komentar tukaj: Medtem ko so relacijske baze podatkov daleč največje prisotnosti na trgu, je poenoten API za obstojnost in omogočanje ponudnikom podatkovnih baz, da tekmujejo glede moči implementacije, ne glede na paradigmo, ki jo uporabljajo ti ponudniki. Ta pristop bi sčasoma lahko pomagal izenačiti pogoje med obema prevladujočima skupinama ponudnikov baz podatkov: dobro zasidranim relacijskim taborom in objektno usmerjenim taborom, ki se bori za tržni delež.

Tri zgoraj našteta odkritja nas vodijo k opredelitvi a obstojnost, ogrodje, ki zagotavlja API Java na visoki ravni za predmete in odnose, da preživi življenjsko dobo okolja izvajalnega okolja (JVM). Tak okvir mora vsebovati naslednje lastnosti:

Preprostost
Minimalni vdor
Transparentnost, kar pomeni, da ogrodje skriva izvajanje shranjevanja podatkov
Dosledni, jedrnati API-ji za shranjevanje / iskanje / posodobitev objektov
Transakcijska podpora, kar pomeni, da ogrodje definira transakcijsko semantiko, povezano z obstojnimi predmeti
Podpora tako za upravljana (npr. Na aplikacijskem strežniku) kot tudi za neupravljana (samostojna) okolja
Podpora potrebnim dodatkom, kot so predpomnjenje, poizvedbe, generiranje primarnega ključa in orodja za preslikavo
Primerne pristojbine za licenciranje - niso tehnična zahteva, vendar vsi vemo, da lahko slaba ekonomija izvrši odličen projekt

Večino zgornjih lastnosti podrobno opisujem v naslednjih oddelkih.

Preprostost

Preprostost je na mojem seznamu zahtevanih lastnosti za kateri koli programski okvir ali knjižnico (glejte uvodni citat tega članka). Razvoj porazdeljenih aplikacij je že dovolj težaven in številni projekti programske opreme propadajo zaradi slabe zapletenosti (in s tem tudi tveganja). Preprosto ni sinonim za poenostavljeno; programska oprema mora imeti vse potrebne funkcije, ki razvijalcu omogočajo, da opravlja svoje delo.

Minimalni vdor

Vsak trajni sistem za shranjevanje vnese določeno količino vdora v kodo aplikacije. Idealna plast obstojnosti mora zmanjšati vdor, da se doseže boljša modularnost in s tem funkcionalnost plug-and-play.

V tem članku vdor opredeljujem kot:

Količina kode, značilne za obstojnost, je razpršena po kodi aplikacije
Potreba po spremembi objektnega modela aplikacije, tako da je treba uporabiti vmesnik za obstojnost - na primer Vztrajno ali podobno - ali s naknadno obdelavo ustvarjene kode

Vdor velja tudi za objektno usmerjene sisteme baz podatkov in čeprav se tam običajno pojavlja manj težav v primerjavi z relacijskimi shrambami podatkov, se lahko med prodajalci ODBMS (objektno usmerjeni sistem za upravljanje baz podatkov) bistveno razlikuje.

Preglednost

Koncept trajne preglednosti plasti je precej preprost: aplikacija uporablja enak API ne glede na vrsto shrambe podatkov (preglednost tipa shranjevanja podatkov) ali prodajalca shrambe podatkov (preglednost prodajalca podatkov). Preglednost močno poenostavi aplikacije in izboljša njihovo vzdrževanje, tako da v največji možni meri skrije podrobnosti o implementaciji shrambe podatkov. Zlasti za razširjene relacijske shrambe podatkov, za razliko od JDBC, vam ni treba trdno kodirati stavkov SQL ali imen stolpcev ali si zapomniti vrstnega reda stolpcev, ki jih vrne poizvedba. Pravzaprav vam ni treba poznati SQL ali relacijske algebre, ker so preveč specifični za izvedbo. Preglednost je morda najpomembnejša lastnost plasti vztrajnosti.

Dosleden, preprost API

API trajne plasti se nanaša na sorazmerno majhen nabor operacij:

Osnovne operacije CRUD (ustvarjanje, branje, posodabljanje, brisanje) na prvovrstnih objektih
Upravljanje transakcij
Upravljanje identitet aplikacij in vztrajnosti
Upravljanje predpomnilnika (tj. Osveževanje in izselitev)
Ustvarjanje in izvajanje poizvedbe

Primer a PersistenceLayer API:

 javna praznina traja (objekt obj); // Shranimo obj v shrambo podatkov. javna obremenitev predmeta (razred c, objekt pK); // branje obj z danim primarnim ključem. posodobitev javne praznine (objekt obj); // Posodobitev spremenjenega predmeta obj. brisanje javne praznine (objekt obj); // izbrišemo obj iz baze podatkov. najdba javne zbirke (poizvedba q); // Poiščimo predmete, ki ustrezajo pogojem naše poizvedbe.

Podpora transakcijam

Dober trajni sloj potrebuje več osnovnih funkcij za zagon, prevzem ali vrnitev transakcije nazaj. Tu je primer:

// razmejitev transakcije (tx). javna void startTx (); public void commitTx (); public void rollbackTx (); // Izberite, da bo trajni predmet navsezadnje prehoden. public void makeTransient (Predmet o)

Opomba: API-ji za razmejitev transakcij se uporabljajo predvsem v neupravljanih okoljih. V upravljanih okoljih vgrajeni upravitelj transakcij pogosto prevzame to funkcionalnost.

Podpora upravljanim okoljem

Upravljana okolja, kot so aplikacijski strežniki J2EE, so postala priljubljena pri razvijalcih. Kdo želi danes pisati srednje stopnje iz nič, ko imamo na voljo odlične strežnike aplikacij? Dostojna plast obstojnosti mora biti sposobna delovati v vsebniku katerega koli večjega strežnika aplikacij EJB (Enterprise JavaBean) in se sinhronizirati s svojimi storitvami, kot sta JNDI (Java Naming and Directory Interface) in upravljanje transakcij.

Poizvedbe

API mora biti sposoben izdajati poljubne poizvedbe za iskanje podatkov. Vključevati bi moral prilagodljiv in zmogljiv, a enostaven za uporabo jezik - API bi moral kot formalne parametre poizvedbe uporabljati predmete Java in ne tabele SQL ali druge predstavitve shrambe podatkov.

Upravljanje predpomnilnika

Upravljanje predpomnilnika lahko naredi čudeže za delovanje aplikacije. Zvočna plast obstojnosti mora zagotavljati popolno predpomnjenje podatkov in ustrezne API-je za nastavitev želenega vedenja, kot so ravni zaklepanja, politike izselitve, lenobno nalaganje in podpora predpomnjenja.

Ustvarjanje primarnega ključa

Zagotavljanje samodejnega ustvarjanja identitete za podatke je ena najpogostejših storitev trajnosti. Vsaka dostojna plast obstojnosti mora zagotavljati generiranje identitete s podporo za vse glavne algoritme za generiranje primarnih ključev. Ustvarjanje primarnega ključa je dobro raziskana težava in obstajajo številni algoritmi primarnih ključev.

Kartiranje, samo za relacijske zbirke podatkov

Pri relacijskih zbirkah podatkov se pojavi težava s preslikavo podatkov: potreba po prevajanju predmetov v tabele in prenašanju odnosov, kot so odvisnosti in sklici, v dodatne stolpce ali tabele. To je samo po sebi netrivialna težava, zlasti pri zapletenih objektnih modelih. Tema objektno-relacijskega modela neskladje impedance presega obseg tega članka, vendar je dobro objavljen. Za več informacij glejte Viri.

Naslednji seznam dodatkov, povezanih s preslikavo in / ali relacijskimi shrambami podatkov, v trajni plasti ni potreben, vendar razvijalcu bistveno olajša življenje:

Orodje za preslikavo GUI (grafični uporabniški vmesnik)
Generatorji kode: Samodejna generacija DDL (jezik za opis podatkov) za ustvarjanje tabel baz podatkov ali samodejna generacija Java kode in preslikava datotek iz DDL
Generatorji primarnih ključev: Podpira več algoritmov za generiranje ključev, kot so UUID, HIGH-LOW in SEQUENCE
Podpora za binarne velike predmete (BLOB) in velike predmete, ki temeljijo na znakih (CLOBs)
Samoreferenčni odnosi: Predmet tipa Bar sklicevanje na drug objekt tipa Bar, na primer
Neobdelana podpora za SQL: Prehodne poizvedbe SQL

Primer

Naslednji delček kode prikazuje, kako uporabljati API obstojne plasti. Recimo, da imamo naslednji model domene: Podjetje ima eno ali več lokacij in vsaka lokacija ima enega ali več uporabnikov. Primer kode aplikacije je lahko naslednje:

PersistenceManager pm = PMFactory.initialize (..); Company co = novo podjetje ("MyCompany"); Lokacija l1 = nova lokacija1 ("Boston"); Lokacija l2 = nova lokacija ("New York"); // Ustvari uporabnike. Uporabnik u1 = novi uporabnik ("Označi"); Uporabnik u2 = novi uporabnik ("Tom"); Uporabnik u3 = novi uporabnik ("Mary"); // Dodaj uporabnike. Uporabnik lahko "pripada" samo eni lokaciji. L1.addUser (u1); L1.addUser (u2); L2.addUser (u3); // Dodajte lokacije podjetju. co.addLocation (l1); co.addLocation (l2); // In na koncu shranimo celotno drevo v bazo podatkov. pm.persist (c);

V drugi seji lahko poiščete podjetja, ki zaposlujejo uporabnika Tom:

PersistenceManager pm = PMFactory.initialize (...) Podjetja za zbiranjeEmploymentingToms = pm.find ("company.location.user.name = 'Tom'");

Za relacijske shrambe podatkov morate ustvariti dodatno datoteko za preslikavo. To bi lahko izgledalo takole:

    Lokacije podjetja Uporabnik

Za ostalo poskrbi obstojna plast, ki zajema naslednje:

Iskanje odvisnih skupin predmetov
Upravljanje identitete predmeta aplikacije
Upravljanje trajnih identitet objektov (primarni ključi)
Vztrajanje vsakega predmeta v ustreznem vrstnem redu
Zagotavljanje upravljanja predpomnilnika
Zagotavljanje ustreznega transakcijskega konteksta (ne želimo, da vztraja le del drevesa predmetov, kajne?)
Zagotavlja uporabniške načine zaklepanja