Pysyvät tiedot Java Data Objects -ohjelmalla, osa 1

"Kaikki pitäisi tehdä mahdollisimman yksinkertaiseksi, mutta ei yksinkertaisemmaksi."

Albert Einstein

Tarve säilyttää ajon aikana luotu data on yhtä vanha kuin laskenta. Tarve tallentaa olio-dataa rajataan, kun olio-ohjelmointi tuli yleiseksi. Tällä hetkellä useimmat modernit, ei-triviaalit sovellukset käyttävät olio-suuntautunutta paradigmaa mallintamaan sovellusalueita. Sitä vastoin tietokantamarkkinat ovat jakautuneet paremmin. Suurin osa tietokantajärjestelmistä käyttää relaatiomallia, mutta objektipohjaiset tietovarastot osoittautuvat välttämättömiksi monissa sovelluksissa. Lisäksi meillä on myös vanhoja järjestelmiä, joihin meidän on usein liityttävä.

Tässä artikkelissa yksilöidään ongelmat, jotka liittyvät tietojen pysyvyyteen kaupallisissa väliohjelmistoympäristöissä, kuten J2EE (Java 2 Platform, Enterprise Edition), ja esitetään, kuinka Java Data Objects (JDO) ratkaisee osan näistä ongelmista. Tässä artikkelissa on yleiskatsaus, ei yksityiskohtainen opetusohjelma, ja se on kirjoitettu sovelluskehittäjän, ei JDO-toteutussuunnittelijan näkökulmasta.

Lue koko sarja Java Data Objects -sovelluksesta:

Osa 1. Tartu ihanteellisen pysyvyyskerroksen takana oleviin ominaisuuksiin
Osa 2. Sun JDO vs. Castor JDO

Niiden Java-kehittäjien, suunnittelijoiden ja J2EE-arkkitehtien, jotka työskentelevät järjestelmissä, joiden on tallennettava tietoja relaatio- tai objektitietokantoihin tai muihin tallennusvälineisiin, tulisi lukea tämä artikkeli. Oletan, että sinulla on perustiedot Java-ohjelmasta ja jonkin verran perehtyneitä objektisuhdekysymyksiin ja terminologiaan.

Läpinäkyvä sitkeys: Miksi vaivautua?

Yli vuosikymmenen ajan jatkuvat yritykset rajata olio-ajoaika ja pysyvyys viittaavat useisiin tärkeisiin havaintoihin (lueteltu tärkeysjärjestyksessä):

Kaikkien pysyvyystietojen tiivistäminen ja puhtaan, yksinkertaisen, olio-sovellusliittymän saaminen tietojen tallentamiseen on ensiarvoisen tärkeää. Emme halua käsitellä pysyvyystietoja ja sisäistä tietojen esittämistä tietovarastoissa, olivat ne sitten relaatio-, olio- tai jotain muuta. Miksi meidän pitäisi käsitellä tietovarastomallin matalan tason rakenteita, kuten rivejä ja sarakkeita, ja kääntää niitä jatkuvasti edestakaisin? Sen sijaan meidän on keskityttävä siihen monimutkaiseen sovellukseen, joka meidän oli toimitettava eilen mennessä.
Haluamme käyttää plug-and-play-lähestymistapaa tietovarastojemme kanssa: Haluamme käyttää erilaisia palveluntarjoajia / toteutuksia muuttamatta sovelluksen lähdekoodiriviä - ja ehkä muuttamatta muutama rivi sopivassa kokoonpanotiedostossa ( s). Toisin sanoen tarvitsemme alan standardin Java-objekteihin perustuvien tietojen saamiseksi, jolla on samanlainen rooli kuin JDBC: llä (Java Database Connectivity) on alan standardina SQL-pohjaisten tietojen saamiseen.
Haluamme käyttää plug-and-play-lähestymistapaa erilaisilla tietokantaparadigmoilla - toisin sanoen haluamme siirtyä relaatiotietokannasta olio-tietokantaan muuttamalla minimaalisesti sovelluskoodia. Vaikka tämä ominaisuus on mukava, sitä käytännössä ei usein tarvita.
Yksi kommentti tässä: Vaikka relaatiotietokannoilla on ylivoimaisesti suurin markkinaosuus, on järkevää tarjota yhtenäinen pysyvyys-sovellusliittymä ja antaa tietovarastopalvelujen tarjoajien kilpailla toteutuksen vahvuuksista riippumatta näiden palveluntarjoajien käyttämästä paradigmasta. Tämä lähestymistapa saattaa lopulta auttaa tasapainottamaan toimintaedellytyksiä kahden hallitsevan tietokantamyyjäryhmän välillä: hyvin vakiintuneen relaatioleirin ja markkinaosuuksien puolesta kamppailevan olio-leirin välillä.

Edellä luetellut kolme löydöstä johtavat meihin määrittelemään a pysyvyyskerros, kehys, joka tarjoaa korkean tason Java-sovellusliittymän objekteille ja suhteille ajoaikaympäristön (JVM) eliniän saavuttamiseksi. Tällaisessa kehyksessä on oltava seuraavat ominaisuudet:

Yksinkertaisuus
Vähäinen tunkeutuminen
Läpinäkyvyys, eli kehys piilottaa tietovaraston toteutuksen
Johdonmukaiset, ytimekkäät API: t objektien tallennukseen / hakuun / päivitykseen
Transaktiotuki, eli kehys määrittelee pysyviin objekteihin liittyvän tapahtumien semantiikan
Tuki sekä hallituille (esim. Sovelluspalvelinpohjaisille) että hallitsemattomille (itsenäisille) ympäristöille
Tuki tarvittaville lisäominaisuuksille, kuten välimuistiin tallentaminen, kyselyt, ensisijaisten avainten luominen ja kartoitustyökalut
Kohtuulliset lisenssimaksut - ei tekninen vaatimus, mutta me kaikki tiedämme, että huono taloustiede voi tuomita erinomaisen projektin

Yksityiskohtaisesti suurimman osan yllä olevista ominaisuuksista seuraavissa kohdissa.

Yksinkertaisuus

Yksinkertaisuus on korkealla luettelossa vaadituista ominaisuuksista minkä tahansa ohjelmistokehyksen tai kirjaston osalta (katso tämän artikkelin aloituslainaus). Hajautettujen sovellusten kehittäminen on jo tarpeeksi vaikeaa, ja monet ohjelmistoprojektit epäonnistuvat huonon monimutkaisuuden (ja riskinhallinnan) vuoksi. Yksinkertainen ei ole synonyymi yksinkertaistettu; ohjelmistolla tulisi olla kaikki tarvittavat ominaisuudet, joiden avulla kehittäjä voi tehdä työnsä.

Vähäinen tunkeutuminen

Jokainen pysyvä tallennusjärjestelmä tuo tietyn määrän tunkeutumista sovelluskoodiin. Ihanteellisen pysyvyyskerroksen tulisi minimoida tunkeutuminen paremman modulaarisuuden ja siten plug-and-play-toiminnallisuuden saavuttamiseksi.

Tässä artikkelissa määritän tunkeutumisen seuraavasti:

Sovelluskoodiin siroteltu pysyvyyskohtaisen koodin määrä
Tarve muokata sovellusobjektimalliasi joko ottamalla käyttöön jokin pysyvyysrajapinta - kuten Pysyvä tai vastaava - tai jälkikäsittelemällä luotu koodi

Tunkeutuminen koskee myös objektisuuntautuneita tietokantajärjestelmiä, ja vaikka niissä onkin yleensä vähemmän ongelmia kuin relaatiotietovarastoissa, se voi vaihdella merkittävästi ODBMS (olio-tietokanta hallintajärjestelmä) -toimittajien välillä.

Läpinäkyvyys

Pysyvän kerroksen läpinäkyvyyskäsite on melko yksinkertainen: sovellus käyttää samaa sovellusliittymää riippumatta tietovarastotyypistä (tietojen tallennustyypin läpinäkyvyys) tai tietovarastojen toimittajista (tietovarastojen toimittajien läpinäkyvyys). Läpinäkyvyys yksinkertaistaa sovelluksia huomattavasti ja parantaa niiden ylläpidettävyyttä piilottamalla tietovarastojen toteutuksen yksityiskohdat mahdollisimman hyvin. Erityisesti yleisten relaatiotietovarastojen kohdalla, toisin kuin JDBC, sinun ei tarvitse koodata SQL-käskyjä tai sarakkeiden nimiä tai muistaa kyselyn palauttamaa sarakejärjestystä. Itse asiassa sinun ei tarvitse tietää SQL: ää tai relaatioalgebraa, koska ne ovat liian toteutuskohtaisia. Läpinäkyvyys on ehkä pysyvyyskerroksen tärkein ominaisuus.

Johdonmukainen, yksinkertainen sovellusliittymä

Pysyvyyskerroksen sovellusliittymä muodostuu suhteellisen pieneksi operaatioiksi:

Ensisijaiset CRUD-toiminnot (luonti, lukeminen, päivittäminen, poistaminen) ensiluokkaisissa kohteissa
Tapahtumien hallinta
Sovellus- ja pysyvyysobjektiidentiteettien hallinta
Välimuistin hallinta (ts. Päivittäminen ja häätö)
Kyselyn luominen ja toteutus

Esimerkki a Pysyvyyskerros API:

 public void persist (Object obj); // Tallenna objekti tietovarastoon. julkinen objektikuorma (luokka c, objekti pK); // Lue obj tietyllä pääavaimella. public void -päivitys (Object obj); // Päivitä muokatun objektin obj. public void delete (Object obj); // Poista obj tietokannasta. julkinen kokoelmahaku (kysely q); // Etsi objektit, jotka täyttävät kyselymme ehdot.

Transaktiotuki

Hyvä pysyvyyskerros tarvitsee useita perustoimintoja aloittaakseen, sitoutuakseen tai palauttaakseen tapahtuman. Tässä on esimerkki:

// Transaktioiden (tx) rajaaminen. public void startTx (); public void sitoutTx (); public void rollbackTx (); // Valitse, haluatko pysyvän objektin olla ohimenevä. public void makeTransient (Object o)

merkintä: Tapahtumien rajaamisen sovellusliittymiä käytetään ensisijaisesti hallitsemattomissa ympäristöissä. Hallinnoiduissa ympäristöissä sisäänrakennettu tapahtumahallinta ottaa usein tämän toiminnon käyttöön.

Hallittujen ympäristöjen tuki

Hallinnoidut ympäristöt, kuten J2EE-sovelluspalvelimet, ovat kasvaneet suosituiksi kehittäjien keskuudessa. Kuka haluaa kirjoittaa keskitasot tyhjästä näinä päivinä, kun meillä on erinomaiset sovelluspalvelimet käytettävissä? Hyvän pysyvyyskerroksen tulisi pystyä toimimaan missä tahansa tärkeimmässä sovelluspalvelimen EJB (Enterprise JavaBean) -säiliössä ja synkronoitua sen palveluiden, kuten JNDI: n (Java Naming and Directory Interface) ja tapahtumien hallinnan kanssa.

Kyselyt

Sovellusliittymän pitäisi pystyä lähettämään mielivaltaisia kyselyjä datahauille. Sen tulisi sisältää joustava ja tehokas, mutta helppokäyttöinen kieli - API: n tulisi käyttää virallisia kyselyparametreja Java-objekteja, ei SQL-taulukoita tai muita tietovarastojen esityksiä.

Välimuistin hallinta

Välimuistin hallinta voi tehdä ihmeitä sovellusten suorituskyvystä. Äänieristyskerroksen tulisi tarjota täysi datan välimuisti sekä sopivat sovellusliittymät halutun toiminnan asettamiseksi, kuten lukitustasot, häätökäytännöt, laiska lataus ja hajautettu välimuistituki.

Ensisijaisen avaimen luominen

Automaattisen henkilöllisyyden luominen tiedoille on yksi yleisimmistä pysyvyyspalveluista. Jokaisen kunnollisen pysyvyyskerroksen tulisi tarjota identiteetin luominen ja tuki kaikille tärkeimmille ensisijaisten avainten luomisalgoritmeille. Ensisijaisen avaimen luonti on hyvin tutkittu asia, ja olemassa on useita ensisijaisen avaimen algoritmeja.

Kartoitus, vain relaatiotietokannoille

Relaatiotietokantojen yhteydessä syntyy tietojen kartoitusongelma: tarve kääntää objektit taulukoiksi ja kääntää suhteet, kuten riippuvuudet ja viitteet, lisäsarakkeiksi tai -taulukoiksi. Tämä on itsessään ei-triviaalinen ongelma, varsinkin monimutkaisten objektimallien kohdalla. Objektisuhdemallin aihe impedanssin epäsuhta ylittää tämän artikkelin soveltamisalan, mutta on hyvin julkistettu. Katso lisätietoja Resursseista.

Seuraavaa luetteloa kartoitukseen ja / tai relaatiotietovarastoihin liittyvistä ekstroista ei vaadita pysyvyyskerroksessa, mutta ne helpottavat kehittäjän elämää huomattavasti:

GUI (graafinen käyttöliittymä) kartoitustyökalu
Koodigeneraattorit: DDL: n (datan kuvauskielen) automaattinen tuottaminen tietokantataulukoiden luomiseksi tai Java-koodin ja kartoitustiedostojen automaattinen luominen DDL: stä
Ensisijaiset avaimen generaattorit: Tukee useita avainten luontialgoritmeja, kuten UUID, HIGH-LOW ja SEQUENCE
Tuki binaarisille suurille kohteille (BLOB) ja merkkipohjaisille suurille kohteille (CLOBit)
Itseviittaussuhteet: Tyyppinen esine Baari viitataan toiseen tyypin objektiin Baari, esimerkiksi
Raaka SQL-tuki: Läpäisevät SQL-kyselyt

Esimerkki

Seuraava koodinpätkä näyttää, kuinka pysyvyyskerros-sovellusliittymää käytetään. Oletetaan, että meillä on seuraava verkkotunnusmalli: Yrityksellä on yksi tai useampia sijainteja ja jokaisella sijainnilla on yksi tai useampi käyttäjä. Seuraava voi olla esimerkkisovelluksen koodi:

PersistenceManager pm = PMFactory.initialize (..); Company co = uusi yritys ("MyCompany"); Sijainti l1 = uusi sijainti1 ("Boston"); Sijainti l2 = uusi sijainti ("New York"); // Luo käyttäjiä. Käyttäjä u1 = uusi käyttäjä ("Mark"); Käyttäjä u2 = uusi käyttäjä ("Tom"); Käyttäjä u3 = uusi käyttäjä ("Mary"); // Lisää käyttäjiä. Käyttäjä voi "kuulua" vain yhteen sijaintiin. L1.addUser (u1); L1.addUser (u2); L2.addUser (u3); // Lisää sijainteja yritykseen. co.addLocation (11); co.addLocation (l2); // Ja lopuksi, tallenna koko puu tietokantaan. pm. vastustaja (c);

Toisessa istunnossa voit etsiä yrityksiä, jotka työllistävät käyttäjän Tom:

PersistenceManager pm = PMFactory.initialize (...) KeräysyrityksetEmployingToms = pm.find ("yritys.sijaintialue.käyttäjänimi = 'Tom'");

Relaatiotietovarastoille sinun on luotava ylimääräinen kartoitustiedosto. Se voi näyttää tältä:

    Yrityssijaintien käyttäjä

Pysyvyyskerros huolehtii lopusta, joka käsittää seuraavat:

Riippuvien objektiryhmien etsiminen
Sovelluskohteen identiteetin hallinta
Pysyvien objektien identiteettien hallinta (ensisijaiset avaimet)
Kukin esine pysyy oikeassa järjestyksessä
Välimuistin hallinnan tarjoaminen
Oikean transaktiokontekstin tarjoaminen (emme halua, että vain osa objektipuusta säilyy, vai mitä?)
Tarjoaa käyttäjän valitsemia lukitustiloja