Išsaugoti duomenis naudojant „Java Data Objects“, 1 dalis

- Viskas turėtų būti kuo paprasčiau, bet ne paprasčiau “.

Albertas Einšteinas

Poreikis išsaugoti duomenis, sukurtus vykdymo metu, yra toks pat senas, kaip ir skaičiavimas. Būtinybė saugoti objektinius duomenis buvo iškirpta, kai objektyvus programavimas tapo visuotinis. Šiuo metu dauguma šiuolaikinių netradicinių programų naudoja objektų orientuotą paradigmą modeliuoti programų domenus. Priešingai, duomenų bazių rinka yra labiau susiskaldžiusi. Daugumoje duomenų bazių sistemų naudojamas reliacinis modelis, tačiau objektu pagrįstos duomenų saugyklos yra būtinos daugelyje programų. Be to, mes taip pat turime senas sistemas, į kurias dažnai turime sąsają.

Šiame straipsnyje nurodomos problemos, susijusios su duomenų išlikimu sandorių tarpinės programinės įrangos aplinkose, tokiose kaip J2EE („Java 2 Platform“, „Enterprise Edition“), ir parodoma, kaip „Java Data Objects“ (JDO) išsprendžia kai kurias iš šių problemų. Šiame straipsnyje pateikiama apžvalga, o ne išsami pamoka ir parašyta iš programų kūrėjų, o ne iš JDO diegimo dizainerių.

Perskaitykite visą „Java Data Objects“ seriją:

1 dalis. Supraskite savybes, slypinčias už idealaus patvarumo sluoksnio
2 dalis. „Sun JDO“ ir „Castor JDO“

Tie „Java“ kūrėjai, dizaineriai ir „J2EE“ architektai, kurie dirba sistemose, kurios turi saugoti duomenis reliacinėse ar objektų duomenų bazėse ar kitose laikmenose, turėtų perskaityti šį straipsnį. Manau, kad jūs turite pagrindines žinias apie „Java“ ir esate šiek tiek susipažinęs su objekto santykio problemomis ir terminologija.

Skaidrus atkaklumas: kam vargintis?

Daugiau nei dešimtmetis nuolatinių bandymų įveikti objektinį vykdymą ir atkaklumą nurodo keletą svarbių pastebėjimų (išvardyti svarbumo tvarka):

Svarbiausia nutraukti bet kokias patvarumo detales ir turėti švarią, paprastą, į objektus orientuotą API duomenų saugojimui. Mes nenorime tvarkyti išsamios informacijos ir vidinio duomenų atvaizdavimo duomenų saugyklose, nesvarbu, ar jie būtų reliaciniai, ar objektiniai, ar dar kažkas. Kodėl turėtume spręsti žemo lygio duomenų saugyklos modelio konstrukcijas, tokias kaip eilutės ir stulpeliai, ir nuolat jas versti pirmyn ir atgal? Vietoj to, mes turime sutelkti dėmesį į tą sudėtingą programą, kurią turėjome pristatyti iki vakarykštės dienos.
Mes norime naudoti „plug-and-play“ metodą savo duomenų saugyklose: norime naudoti skirtingus teikėjus / diegimus nekeisdami programos šaltinio kodo eilutės ir galbūt nekeisdami daugiau nei kelių eilučių atitinkamame konfigūracijos faile ( s). Kitaip tariant, mums reikia pramonės standarto, kad galėtume pasiekti duomenis, pagrįstus „Java“ objektais. Tas vaidmuo, panašus į tą, kurį atlieka JDBC („Java Database Connectivity“), yra pramonės standartas norint pasiekti SQL pagrįstus duomenis.
Mes norime naudoti „plug-and-play“ metodą su skirtingomis duomenų bazių paradigmomis - tai yra, mes norime pereiti iš reliacinės duomenų bazės į objektyvią su minimaliais programos kodo pakeitimais. Nors ir malonu, tačiau praktiškai šios galimybės nereikia.
Vienas komentaras čia: Nors reliacinės duomenų bazės kol kas turi didžiausią rinkos dalyvavimą, yra prasminga teikti vieningą patvarumo API ir leisti duomenų saugyklų teikėjams konkuruoti dėl stipriųjų pusių, neatsižvelgiant į tai, kokią paradigmą jie naudoja. Šis požiūris galų gale gali padėti suvienodinti sąlygas dviem dominuojančioms duomenų bazių pardavėjų grupėms: gerai įsitvirtinusiai santykių stovyklai ir kovai dėl rinkos dalinio objekto.

Trys aukščiau išvardyti atradimai leidžia mums apibrėžti a patvarumo sluoksnis, sistema, teikianti aukšto lygio „Java“ API objektams ir ryšiams, kad jie pralenktų vykdymo aplinkos (JVM) gyvenimo trukmę. Tokioje sistemoje turi būti šios savybės:

Paprastumas
Minimalus įsibrovimas
Skaidrumas, o tai reiškia, kad sistema slepia duomenų saugyklos įgyvendinimą
Nuoseklios, glaustos API objektų saugojimui / paieškai / atnaujinimui
Operacijų palaikymas, tai reiškia, kad sistema apibrėžia sandorių semantiką, susijusią su nuolatiniais objektais
Palaikymas tiek valdomoje (pvz., Programų serveryje), tiek ir nevaldomoje (atskira) aplinkoje
Palaikymas būtiniems priedams, tokiems kaip talpinimas, užklausos, pirminio rakto generavimas ir žemėlapių sudarymo įrankiai
Pagrįsti licencijavimo mokesčiai - ne techninis reikalavimas, tačiau visi žinome, kad prasta ekonomika gali pasmerkti puikų projektą

Daugumą aukščiau nurodytų savybių detalizuoju tolesniuose skyriuose.

Paprastumas

Paprastumas yra didelis mano reikalaujamų bet kurios programinės įrangos ar bibliotekos bruožų sąraše (žr. Šio straipsnio pradinę citatą). Kurti paskirstytas programas jau yra pakankamai sunku, todėl daugelis programinės įrangos projektų žlunga dėl prasto kompleksiškumo (ir, iš esmės, rizikos) valdymo. Paprasta nėra sinonimas supaprastinta; programinė įranga turėtų turėti visas reikalingas funkcijas, leidžiančias kūrėjui atlikti savo darbą.

Minimalus įsibrovimas

Kiekviena nuolatinė saugojimo sistema įveda tam tikrą įsibrovimą į programos kodą. Idealus patvarumo sluoksnis turėtų sumažinti įsibrovimą, kad būtų pasiektas geresnis moduliškumas ir tokiu būdu „plug-and-play“ funkcionalumas.

Šiame straipsnyje įsibrovimą apibrėžiu kaip:

Specifinio patvarumo kodo, išsibarsčiusio per programos kodą, kiekis
Būtinybė modifikuoti programos objekto modelį arba įdiegiant tam tikrą patvarumo sąsają, pvz., Patvarus ar pan. - arba apdorojant sugeneruotą kodą

Įsilaužimas taip pat taikomas į objektą orientuotoms duomenų bazių sistemoms ir, nors jose paprastai yra mažiau problemų, palyginti su reliacinių duomenų saugyklomis, ODBMS (objektinės duomenų bazių valdymo sistemos) tiekėjai gali labai skirtis.

Skaidrumas

Nuolatinio sluoksnio skaidrumo samprata yra gana paprasta: programa naudoja tą patį API, neatsižvelgdama į duomenų saugyklos tipą (duomenų saugyklos tipo skaidrumas) arba duomenų saugyklos tiekėją (duomenų saugyklos tiekėjo skaidrumas). Skaidrumas labai supaprastina programas ir pagerina jų prieinamumą, maksimaliai paslėpdamas duomenų saugyklos įgyvendinimo detales. Visų pirma, skirtingai nei JDBC, paplitusiose reliacinių duomenų saugyklose jums nereikia koduoti SQL sakinių ar stulpelių pavadinimų arba prisiminti stulpelių tvarką, kurią grąžina užklausa. Tiesą sakant, jums nereikia žinoti SQL ar reliacinės algebros, nes jie per daug konkretūs. Skaidrumas yra bene svarbiausias patvarumo sluoksnio bruožas.

Nuosekli, paprasta API

Patvarumo sluoksnio API susiveda į palyginti nedidelį operacijų rinkinį:

Pirminės CRUD (kūrimo, skaitymo, atnaujinimo, ištrynimo) operacijos su pirmos klasės objektais
Sandorių valdymas
Taikymo ir patvarumo objektų tapatybių valdymas
Talpyklos tvarkymas (t. Y. Atnaujinimas ir iškeldinimas)
Užklausos kūrimas ir vykdymas

A pavyzdys PersistenceLayer API:

 public void persist (Object obj); // Išsaugoti objektą duomenų saugykloje. viešoji objekto apkrova (c klasė, objektas pK); // Perskaitykite obj su nurodytu pirminiu raktu. public void update (Object obj); // Atnaujinti pakeistą objekto objektą. public void delete (Object obj); // Ištrinti obj iš duomenų bazės. viešas kolekcijos radinys (užklausa q); // Raskite objektus, kurie atitinka mūsų užklausos sąlygas.

Operacijų palaikymas

Geram patvarumo sluoksniui reikia kelių elementarių funkcijų, kad būtų galima pradėti, įvykdyti arba sugrąžinti operaciją. Štai pavyzdys:

// Operacijų (tx) atribojimas. public void startTx (); viešas negaliojantis įsipareigojimasTx (); public void rollbackTx (); // Vis dėlto pasirinkite, kad nuolatinis objektas būtų laikinas. public void makeTransient (objektas o)

Pastaba: Operacijų ribų nustatymo API pirmiausia naudojamos nevaldomoje aplinkoje. Valdomoje aplinkoje įmontuotas operacijų tvarkytuvas dažnai prisiima šią funkciją.

Palaikoma valdoma aplinka

Valdomos aplinkos, tokios kaip „J2EE“ programų serveriai, išpopuliarėjo tarp kūrėjų. Kas šiais laikais nori parašyti vidurines pakopas nuo nulio, kai turime puikių programų serverių? Tinkamas patvarumo sluoksnis turėtų sugebėti dirbti bet kurio pagrindinio programų serverio EJB („Enterprise JavaBean“) talpykloje ir sinchronizuoti su jo paslaugomis, tokiomis kaip JNDI („Java“ pavadinimų ir katalogų sąsaja) ir operacijų valdymu.

Užklausos

API turėtų galėti pateikti savavališkas duomenų paieškų užklausas. Joje turėtų būti lanksti ir galinga, tačiau lengvai naudojama kalba - API kaip oficialius užklausos parametrus turėtų naudoti „Java“ objektus, o ne SQL lenteles ar kitus duomenų saugyklos vaizdus.

Talpyklos valdymas

Talpyklos tvarkymas gali padaryti stebuklus dėl programos našumo. Garso patvarumo sluoksnis turėtų suteikti visišką duomenų talpyklą ir atitinkamas API, kad būtų galima nustatyti norimą elgseną, pvz., Užrakinimo lygius, iškeldinimo politiką, tingų įkėlimą ir paskirstytą talpyklą.

Pirminis raktų generavimas

Automatinio duomenų tapatumo generavimas yra viena iš labiausiai paplitusių atkaklumo paslaugų. Kiekvienas padorus patvarumo sluoksnis turėtų suteikti tapatybės generavimą ir palaikymą visiems pagrindiniams pirminių raktų generavimo algoritmams. Pirminio rakto generavimas yra gerai ištirtas klausimas ir egzistuoja daugybė pirminio rakto algoritmų.

Susiejimas, skirtas tik reliacinėms duomenų bazėms

Naudojant reliacines duomenų bazes, iškyla duomenų susiejimo problema: reikia išversti objektus į lenteles ir išversti ryšius, pvz., Priklausomybes ir nuorodas, į papildomus stulpelius ar lenteles. Tai savaime yra nereikšminga problema, ypač sudėtingų objektų modeliuose. Objektinio-reliacinio modelio tema impedanso neatitikimas viršija šio straipsnio taikymo sritį, tačiau yra gerai paskelbta. Daugiau informacijos žr. Ištekliai.

Toliau pateikiamas priedų, susijusių su žemėlapių sudarymu ir (arba) reliacinių duomenų saugyklomis, sąrašas nėra būtinas patvarumo sluoksnyje, tačiau jie žymiai palengvina kūrėjo gyvenimą:

GUI (grafinės vartotojo sąsajos) atvaizdavimo įrankis
Kodo generatoriai: DDL (duomenų aprašymo kalbos) automatinis sugeneravimas duomenų bazių lentelėms sukurti arba „Java“ kodo ir failų susiejimo iš DDL automatinis sugeneravimas
Pagrindiniai raktų generatoriai: Palaikomi keli raktų generavimo algoritmai, tokie kaip UUID, HIGH-LOW ir SEQUENCE
Dvejetainių didelių objektų (BLOB) ir simboliais pagrįstų didelių objektų palaikymas (CLOB)
Savireferenciniai santykiai: Tipo objektas Baras nurodant kitą tipo objektą Baras, pavyzdžiui
Neapdorotas SQL palaikymas: Perduoti SQL užklausas

Pavyzdys

Šis kodo fragmentas parodo, kaip naudoti patvarumo sluoksnio API. Tarkime, kad turime tokį domeno modelį: įmonė turi vieną ar daugiau vietų ir kiekviena vieta turi vieną ar daugiau vartotojų. Tai gali būti programos kodo pavyzdys:

PersistenceManager pm = PMFactory.inicialize (..); „Company co“ = nauja įmonė („MyCompany“); Vieta l1 = nauja vieta1 („Bostonas“); Vieta l2 = nauja vieta („Niujorkas“); // Sukurti vartotojus. Vartotojas u1 = naujas vartotojas („Pažymėti“); Vartotojas u2 = naujas vartotojas („Tomas“); Vartotojas u3 = naujas vartotojas („Marija“); // Pridėti vartotojų. Vartotojas gali „priklausyti“ tik vienai vietai. L1.addUser (u1); L1.addUser (u2); L2.addUser (u3); // Pridėti vietas prie įmonės. co.addLocation (l1); co.addLocation (l2); // Ir galiausiai saugokite visą medį duomenų bazėje. pm. atstovas (c);

Kitoje sesijoje galite ieškoti įmonių, kuriose dirba vartotojas Tomas:

PersistenceManager pm = PMFactory.inicialize (...) Inkasavimo įmonėsEmployingToms = pm.find ("company.location.user.name = 'Tom'");

Norėdami sukurti reliacinių duomenų saugyklas, turite sukurti papildomą susiejimo failą. Tai gali atrodyti taip:

    Įmonės vietų naudotojas

Patvarumo sluoksnis rūpinasi likusiu, kuris apima:

Priklausomų objektų grupių paieška
Programos objekto tapatybės valdymas
Nuolatinių objektų tapatybių valdymas (pagrindiniai raktai)
Kiekvieno objekto atkaklumas atitinkama tvarka
Talpyklos tvarkymas
Tinkamo operacijų konteksto pateikimas (mes nenorime, kad išliktų tik dalis objekto medžio, ar ne?)
Vartotojo pasirenkamų užrakinimo režimų teikimas