Kohteen pysyvyys ja Java

Esineen kestävyys tai sitkeys, on usein kuullut termi, jota käytetään yhdessä objektien tallentamisen tietokantoihin kanssa. Pysyvyyden odotetaan toimivan kaupan eheydellä, ja sellaisenaan siihen sovelletaan tiukkoja ehtoja. (Katso tämän artikkelin Resurssit-osiosta lisätietoja tapahtumien käsittelystä.) Sen sijaan vakiokielisten kirjastojen ja pakettien kautta tarjotuissa kielipalveluissa ei usein ole tapahtumarajoituksia.

Kuten näemme tästä artikkelista, todisteet viittaavat siihen, että yksinkertainen Java-pysyvyys johtuu todennäköisesti itse kielestä, kun taas tietokantatoimittajat tarjoavat hienostuneita tietokantatoimintoja.

Mikään esine ei ole saari

Todellisessa maailmassa löydät harvoin kohteen, jolla ei ole suhdetta muihin esineisiin. Objektit ovat komponentteja esineiden mallit. Kohteen kestävyyskysymys ylittää objektimallin kestävyyden ja jakautumisen kysymyksen, kun olemme havainneet, että objektit ovat yhteydessä toisiinsa niiden suhteiden perusteella.

Suhteellinen lähestymistapa tietojen tallentamiseen pyrkii yhdistämään tiedot tyypin mukaan. Taulukon rivit edustavat levyllä olevien samantyyppisten objektien fyysistä aggregaattia. Objektien välisiä suhteita edustavat sitten avaimet, jotka jaetaan monien taulukoiden kesken. Vaikka relaatiotietokannat organisoivat tietokantojen järjestämisen kautta, ne antavat joskus mahdollisuuden käyttää yhdessä taulukoita, joita todennäköisesti käytetään yhdessä ryhmitelty) samassa loogisessa osiossa, kuten tietokantasegmentissä, niillä ei ole mekanismia objektisuhteiden tallentamiseksi tietokantaan. Näin ollen objektimallin rakentamiseksi nämä suhteet rakennetaan olemassa olevista avaimista ajon aikana prosessissa, johon viitataan taulukko liittyy. Tämä on sama tunnettu relaatiotietokantojen ominaisuus tietojen riippumattomuus. Lähes kaikki objektitietokantojen muunnelmat tarjoavat jonkinlaisen mekanismin järjestelmän suorituskyvyn parantamiseksi, johon liittyy monimutkaisia ​​objektisuhteita perinteisiin relaatiotietokantoihin verrattuna.

Kyselyyn tai navigointiin?

Tallennettaessa objekteja levylle kohtaamme vaihtoehdon sijoittaa toisiinsa liittyvät objektit, jotta ne mukautuvat paremmin navigointiin, tai tallentaa esineitä taulukkomaisiin kokoelmiin, jotka kokoavat objektit tyypin mukaan predikaattipohjaisen käytön (kyselyt) tai molempien helpottamiseksi. . Kohteiden rinnakkaissijainti pysyvässä tallennustilassa on alue, jolla relaatio- ja olio-tietokannat eroavat toisistaan ​​suuresti. Kyselykielen valinta on toinen näkökohta. Strukturoitu kyselykieli (SQL) ja sen laajennukset ovat tarjonneet relaatiojärjestelmille predikaattipohjaisen pääsymekanismin. Object Query Language (OQL) on ODMG: n standardoima SQL-objektivariantti, mutta tämän kielen tuki on tällä hetkellä vähäistä. Polymorfiset menetelmät tarjoavat ennennäkemättömän tyylikkyyden rakennettaessa semanttinen kysely objektikokoelmalle. Kuvittele esimerkiksi polymorfinen käyttäytyminen tili olla nimeltään isInGoodStanding. Se voi palauttaa Boolen arvon tosi kaikille hyvässä asemassa oleville tileille ja väärin muuten. Kuvittele nyt eleganssia kysellä tilikokoelmaa, missä hyvässä asemassa toteutetaan eri tavalla liiketoimintasääntöjen perusteella kaikilla hyvässä asemassa olevilla tileillä. Se voi näyttää tältä:

setOfGoodCustomers = setOfAccounts.query (account.inGoodStanding ());

Vaikka useat olemassa olevista objektitietokannoista pystyvät käsittelemään tällaisen kyselytyylin C ++: ssa ja Smalltalkissa, niiden on vaikea tehdä niin suuremmille (esimerkiksi yli 500 gigatavun kokoelmille) ja monimutkaisemmille kyselylausekkeille. Useat relaatiotietokantayrityksistä, kuten Oracle ja Informix, tarjoavat pian toisen, SQL-pohjaisen syntaksin saman tuloksen saavuttamiseksi.

Pysyvyys ja tyyppi

Kohdekeskeinen kielen harrastaja sanoisi, että pysyvyys ja tyyppi ovat objektin ortogonaalisia ominaisuuksia; toisin sanoen samantyyppiset pysyvät ja ohimenevät kohteet voivat olla identtisiä, koska yhden ominaisuuden ei pitäisi vaikuttaa toiseen. Vaihtoehtoisen näkemyksen mukaan pysyvyys on käyttäytymistä, jota tukevat vain pysyvät objektit, ja tiettyä käyttäytymistä voidaan soveltaa vain pysyviin kohteisiin. Jälkimmäinen lähestymistapa vaatii menetelmiä, jotka opastavat pysyviä objekteja tallentamaan itsensä ja hankkimaan itsensä pysyvästä tallennustilasta, kun taas ensimmäinen tarjoaa sovellukselle saumattoman kuvan koko objektimallista - usein laajentamalla virtuaalimuistijärjestelmää.

Kanonisointi ja kielen riippumattomuus

Kielen samantyyppiset objektit tulisi tallentaa pysyvään muistiin samalla asettelulla riippumatta niiden käyttöliittymien järjestyksestä. Prosessi, jolla objektiasettelu muunnetaan tähän yleiseen muotoon, kutsutaan yhdessä objektin esityksen kanonisoinniksi. Käännetyissä kielissä, joissa on staattinen kirjoittaminen (ei Java), samalla kielellä kirjoitetut, mutta eri järjestelmissä kootut objektit tulisi edustaa identtisesti pysyvässä tallennustilassa.

Kanonisoinnin laajennus käsittelee kielestä riippumattoman objektin esityksen. Jos esineitä voidaan edustaa kielestä riippumattomalla tavalla, saman objektin eri esitykset voivat jakaa saman pysyvän tallennustilan.

Yksi mekanismi tämän tehtävän suorittamiseksi on ottaa käyttöön ylimääräinen epäsuoruuden taso rajapinnan määrityskielen (IDL) kautta. Objektitietokannan rajapinnat voidaan tehdä IDL: n ja vastaavien tietorakenteiden kautta. IDL-tyylisten sidosten haittapuoli on kaksiosainen: Ensinnäkin ylimääräinen epäsuoruuden taso vaatii aina ylimääräisen käännöstason, mikä vaikuttaa järjestelmän yleiseen suorituskykyyn; toiseksi, se rajoittaa tietyille toimittajille ainutlaatuisten tietokantapalvelujen käyttöä ja saattaa olla arvokasta sovelluskehittäjille.

Samanlainen mekanismi on tukea objektipalveluita SQL: n laajennuksella. Relaatiotietokantatoimittajat ja pienemmät objekti- / relaatiotoimittajat ovat tämän lähestymistavan kannattajia; Kuitenkin kuinka menestyksekkäästi nämä yritykset menestyvät esineiden varastoinnin puitteiden luomisessa, on vielä nähtävissä.

Mutta kysymys on edelleen: Onko objektin pysyvyys osa objektin käyttäytymistä vai onko se ulkopuolinen palvelu, jota tarjotaan esineille erillisten rajapintojen kautta? Entä esineiden kokoelmat ja menetelmät niiden kyselemiseksi? Suhteellinen, laajennettu relaatio ja objekti / relaatio-lähestymistavat kannattavat yleensä kielen erottamista, kun taas objektitietokannat - ja itse Java-kieli - pitävät pysyvyyttä kielen luontaisena.

Natiivi Java-pysyvyys sarjallisuuden avulla

Objektisarja on Java-kielikohtainen mekanismi Java-objektien ja primitiivien tallentamiseen ja hakemiseen virtauksiin. On syytä huomata, että vaikka kaupalliset kolmansien osapuolten kirjastot C ++ -objektien sarjallisuutta varten ovat olleet jo jonkin aikaa, C ++ ei ole koskaan tarjonnut natiivimekanismia objektien sarjoitukseen. Näin käytät Java-sarjoitusta:

// "foo": n kirjoittaminen streamiin (esimerkiksi tiedostoon) 
// Vaihe 1. Luo lähtövirta 
// eli luo ämpäri tavujen vastaanottamiseksi 
FileOutputStream out = uusi FileOutputStream ("fooFile"); 
// Vaihe 2. Luo ObjectOutputStream 
// eli luo letku ja laita sen pää ämpäriin 
ObjectOutputStream os = uusi ObjectOutputStream (out) 
// Vaihe 3. Kirjoita merkkijono ja objekti streamiin 
// eli anna virtauksen virrata kauhaan 
os.writeObject ("foo"); 
os.writeObject (uusi Foo ()); 
// Vaihe 4. Huuhtele tiedot määränpäähänsä 
os huuhtele (); 

Writeobject method sarjoittaa foo: n ja sen transitiivisen sulkemisen - eli kaikki objektit, joihin foo voidaan viitata kaaviossa. Suoratoistossa on vain yksi kopio sarjatuotetusta objektista. Muut viittaukset kohteisiin tallennetaan objektikahvoina tilan säästämiseksi ja pyöreiden viitteiden välttämiseksi. Sarjattu objekti alkaa luokassa, jota seuraavat kunkin luokan kentät perintöhierarkiassa.

// Objektin lukeminen virrasta 
// Vaihe 1. Luo tulovirta 
FileInputStream sisään = uusi FileInputStream ("fooFile"); 
// Vaihe 2. Luo objektin tulovirta 
ObjectInputStream ins = uusi ObjectInputStream (sisään); 
// Vaihe 3. Sain tietää, mitä luet 
Merkkijono fooString = (Merkkijono) ins.readObject (); 
Foo foo = (Foo) s.readObject (); 

Esineiden sarjallisuus ja suojaus

Oletusarvon mukaan sarjallisuus kirjoittaa ja lukee ei-staattiset ja ei-ohimenevät kentät virrasta. Tätä ominaisuutta voidaan käyttää suojausmekanismina ilmoittamalla kentät, joita ei voi järjestää sarjoiksi, yksityisiksi transienteiksi. Jos luokkaa ei välttämättä järjestetä lainkaan, writeObject ja readObject menetelmät olisi toteutettava heittää NoAccessException.

Pysyvyys kaupan eheyden kanssa: Esittelyssä JDBC

X / Openin SQL CLI: n (Client Level Interface) ja Microsoftin ODBC-abstraktioiden pohjalta mallinnettu Java-tietokantayhteyden (JDBC) tavoitteena on tarjota tietokantayhteysmekanismi, joka on riippumaton taustalla olevasta tietokannan hallintajärjestelmästä (DBMS) .JDBC-yhteensopiviksi ohjaimet täytyy tukea vähintään ANSI SQL-2 -tason API: ta, joka antaa kolmannen osapuolen työkalujen toimittajille ja sovelluksille riittävästi joustavuutta pääsyyn tietokantoihin.

JDBC on suunniteltu yhdenmukaiseksi muun Java-järjestelmän kanssa. Toimittajia kannustetaan kirjoittamaan API, joka on kirjoitettu vahvemmin kuin ODBC, mikä tarjoaa suuremman staattisen tyyppitarkistuksen kääntöhetkellä.

Tässä on kuvaus tärkeimmistä JDBC-liitännöistä:

• java.sql.Driver.Manager hoitaa ohjainten lataamisen ja tukee uusia tietokantayhteyksiä.

• java.sql.Connection edustaa yhteyttä tiettyyn tietokantaan.

• java.sql.Lausunto toimii säilönä SQL-käskyn suorittamiseksi tietylle yhteydelle.

• java.sql.ResultSet ohjaa pääsyä tulosjoukkoon.

Voit ottaa JDBC-ohjaimen käyttöön useilla tavoilla. Yksinkertaisin olisi rakentaa kuljettaja siltana ODBC: hen. Tämä lähestymistapa sopii parhaiten työkaluille ja sovelluksille, jotka eivät vaadi korkeaa suorituskykyä. Laajennettavissa oleva muotoilu tuo ylimääräisen epäsuoruuden DBMS-palvelimelle tarjoamalla JDBC-verkkoajurin, joka käyttää DBMS-palvelinta julkaistun protokollan kautta. Tehokkain ohjain pääsisi kuitenkin suoraan DBMS: n omaan sovellusliittymään.

Objektitietokannat ja Java-pysyvyys

Useat alalla käynnissä olevat projektit tarjoavat Java-pysyvyyttä objektitasolla. Tästä kirjoituksesta lähtien Object Designin PSE (Persistent Storage Engine) ja PSE Pro ovat kuitenkin ainoat käytettävissä olevat Java-pohjaiset, olio-tietokantapaketit (ainakin, joista olen tietoinen). Katso Resurssit-osiosta lisätietoja PSE: stä ja PSE Prosta.

Java-kehitys on johtanut poikkeamiseen ohjelmistotoimittajien perinteisestä kehitysparadigmasta etenkin kehitysprosessin aikajanalla. Esimerkiksi PSE ja PSE Pro kehitetään heterogeenisessä ympäristössä. Ja koska kehitysprosessissa ei ole linkitysvaihetta, kehittäjät ovat pystyneet luomaan erilaisia ​​toisistaan ​​riippumattomia toiminnallisia komponentteja, mikä johtaa parempaan ja luotettavampaan olio-koodiin.

PSE Pro pystyy palauttamaan vioittuneen tietokannan keskeytetystä tapahtumasta, joka johtuu järjestelmän virheestä. Luokat, jotka ovat vastuussa tästä lisätoiminnosta, eivät ole PSE-julkaisussa. Näiden kahden tuotteen välillä ei ole muita eroja. Näitä tuotteita kutsutaan "dribblewareiksi" - ohjelmistojulkaisut, jotka parantavat niiden toimivuutta kytkemällä uusia komponentteja. Ei niin kaukaisessa tulevaisuudessa ajatus ostaa suuria, monoliittisia ohjelmistoja olisi menneisyyttä. Kyberavaruuden uusi liiketoimintaympäristö yhdessä Java-tietojenkäsittelyn kanssa mahdollistavat käyttäjien ostaa vain tarvitsemansa objektimallin (objektikaavion) ​​osat, mikä johtaa pienempiin lopputuotteisiin.

PSE toimii jälkikäsittelemällä ja merkitsemällä luokkatiedostot sen jälkeen, kun kehittäjä on luonut ne. PSE: n näkökulmasta objektigrafiikan luokat ovat joko pysyviä tai pysyviä. Pysyvästi kykenevät luokat voivat pysyä itsessään, kun taas pysyviä tietoiset luokat voivat toimia pysyvissä kohteissa. Tämä ero on välttämätön, koska pysyvyys ei välttämättä ole toivottu käytös tietyille luokille. Luokkatiedoston jälkikäsittelijä tekee seuraavat muutokset luokkiin: