Trvanlivosť predmetu, príp vytrvalosť, je termín, ktorý často počujete v spojení s otázkou ukladania objektov do databáz. Očakáva sa, že persistencia bude pracovať s transakčnou integritou, a preto podlieha prísnym podmienkam. (Ďalšie informácie o spracovaní transakcií nájdete v časti Zdroje tohto článku.) Naproti tomu jazykové služby ponúkané prostredníctvom knižníc a balíkov štandardných jazykov často neobsahujú transakčné obmedzenia.
Ako uvidíme v tomto článku, dôkazy naznačujú, že jednoduchá vytrvalosť v prostredí Java bude pravdepodobne pochádzať zo samotného jazyka, zatiaľ čo sofistikované funkcie databázy budú ponúkané predajcami databáz.
Žiadny objekt nie je ostrov
V skutočnom svete zriedka nájdete objekt, ktorý nemá vzťahy s inými objektmi. Objekty sú súčasťou objektové modely. Otázka trvanlivosti objektu presahuje otázku trvanlivosti a distribúcie objektového modelu, akonáhle urobíme pozorovanie, že objekty sú vzájomne prepojené na základe vzájomných vzťahov.
Relačný prístup k ukladaniu údajov má tendenciu agregovať údaje podľa typu. Riadky v tabuľke predstavujú fyzický agregát objektov rovnakého typu na disku. Vzťahy medzi objektmi sú potom predstavované kľúčmi, ktoré sú zdieľané v mnohých tabuľkách. Relačné databázy, aj keď prostredníctvom organizácie databázy, niekedy umožňujú spoločné vyhľadanie tabuliek, ktoré sa pravdepodobne budú používať spoločne (alebo zoskupené) v rovnakom logickom oddiele, ako je napríklad databázový segment, nemajú žiadny mechanizmus na ukladanie vzťahov objektov v databáze. Preto, aby sa vytvoril objektový model, sú tieto vzťahy skonštruované z existujúcich kľúčov za behu procesu, ktorý sa označuje ako stôl sa pripája. Toto je rovnaká známa vlastnosť volaných relačných databáz nezávislosť údajov. Takmer všetky varianty objektových databáz ponúkajú určitý mechanizmus na zvýšenie výkonu systému, ktorý zahŕňa zložité objektové vzťahy nad tradičnými relačnými databázami.
Dotazovať sa alebo navigovať?
Pri ukladaní objektov na disk stojíme pred voľbou spoločného umiestnenia súvisiacich objektov, aby sa lepšie prispôsobil navigačnému prístupu, alebo aby sme objekty ukladali do kolekcií podobných tabuľkám, ktoré agregujú objekty podľa typu, aby sa uľahčil prístup založený na prediktoch (dotazy), alebo oboje. . Spoločné umiestnenie objektov v trvalom úložisku je oblasťou, kde sa relačné a objektovo orientované databázy veľmi líšia. Ďalšou oblasťou úvah je výber dotazovacieho jazyka. Štruktúrovaný dotazovací jazyk (SQL) a jeho rozšírenia poskytli relačným systémom prístupový mechanizmus založený na predikátoch. Object Query Language (OQL) je objektový variant jazyka SQL, ktorý štandardizuje ODMG, ale podpora tohto jazyka je momentálne nedostatočná. Polymorfné metódy ponúkajú bezprecedentnú eleganciu pri konštrukcii sémantického dotazu na kolekciu objektov. Napríklad si predstavte polymorfné správanie pre zúčt zavolal isInGoodStanding. Môže vrátiť booleovskú hodnotu true pre všetky účty v dobrom stave, inak false. Teraz si predstavte eleganciu dotazovania sa na zbierku účtov, kde inGoodStanding sa implementuje odlišne na základe obchodných pravidiel pre všetky účty v dobrom stave. Môže to vyzerať napríklad takto:
setOfGoodCustomers = setOfAccounts.query (account.inGoodStanding ());
Aj keď niekoľko existujúcich databáz objektov dokáže spracovať taký štýl dotazu v jazykoch C ++ a Smalltalk, je ťažké ich urobiť pre väčšie (napríklad 500 a viac gigabajtové) kolekcie a zložitejšie výrazy dotazov. Niekoľko spoločností zaoberajúcich sa relačnou databázou, ako napríklad Oracle a Informix, čoskoro ponúkne inú syntax založenú na SQL, aby dosiahli rovnaký výsledok.
Perzistencia a typ
Milovník objektovo orientovaného jazyka by povedal, že perzistencia a typ sú ortogonálne vlastnosti objektu; to znamená, že trvalé a prechodné objekty rovnakého typu môžu byť totožné, pretože jedna vlastnosť by nemala ovplyvňovať druhú. Alternatívny názor tvrdí, že perzistencia je správanie podporované iba perzistentnými objektmi a určité správanie sa môže vzťahovať iba na perzistentné objekty. Posledný prístup vyžaduje metódy, ktoré ukladajú príkazom trvalým objektom ukladať a načítať sa z trvalého úložiska, zatiaľ čo prvý poskytuje aplikácii bezproblémový pohľad na celý objektový model - často rozšírením systému virtuálnej pamäte.
Kanonizácia a jazyková nezávislosť
Objekty rovnakého typu v jazyku by mali byť uložené v trvalom úložisku s rovnakým rozložením bez ohľadu na poradie, v akom sa zobrazujú ich rozhrania. Procesy transformácie rozloženia objektov na tento bežný formát sa súhrnne označujú ako kanonizácia reprezentácie objektov. V kompilovaných jazykoch so statickým písaním (nie Java) by mali byť objekty napísané v rovnakom jazyku, ale kompilované pod rôznymi systémami, v perzistentnom úložisku identicky zastúpené.
Rozšírenie kanonizácie sa zameriava na jazykovo nezávislé znázornenie objektov. Ak môžu byť objekty reprezentované jazykovo nezávislým spôsobom, bude možné, aby rôzne reprezentácie toho istého objektu zdieľali rovnaké trvalé úložisko.
Jedným z mechanizmov na splnenie tejto úlohy je zavedenie ďalšej úrovne neprítomnosti prostredníctvom definičného jazyka rozhrania (IDL). Rozhrania objektovej databázy je možné vytvárať prostredníctvom IDL a zodpovedajúcich dátových štruktúr. Nevýhoda väzieb v štýle IDL je dvojaká: Po prvé, mimoriadna úroveň indirection vyžaduje vždy ďalšiu úroveň prekladu, ktorá ovplyvňuje celkový výkon systému; po druhé, obmedzuje použitie databázových služieb, ktoré sú jedinečné pre konkrétnych dodávateľov a ktoré by mohli byť cenné pre vývojárov aplikácií.
Podobným mechanizmom je podpora objektových služieb prostredníctvom rozšírenia SQL. Navrhovatelia tohto prístupu sú predajcovia relačných databáz a menší predajcovia objektov / vzťahov. Ako úspešné však budú tieto spoločnosti pri formovaní rámca pre ukladanie objektov, sa ešte len uvidí.
Otázkou však zostáva: Je perzistencia objektu súčasťou správania objektu alebo je to externá služba ponúkaná objektom prostredníctvom samostatných rozhraní? Čo tak zbierky predmetov a metódy ich dopytovania? Relačné, rozšírené relačné a objektové / relačné prístupy majú tendenciu obhajovať oddelenie medzi jazykom, zatiaľ čo objektové databázy - a samotný jazyk Java - vidia perzistenciu ako vnútornú pre jazyk.
Natívna vytrvalosť v prostredí Java prostredníctvom serializácie
Serializácia objektov je mechanizmus špecifický pre jazyk Java na ukladanie a načítanie objektov Java a primitívov do streamov. Je potrebné poznamenať, že hoci komerčné knižnice tretích strán na serializáciu objektov C ++ existujú už nejaký čas, C ++ nikdy neponúklo natívny mechanizmus na serializáciu objektov. Tu je príklad, ako používať serializáciu Java:
// Zápis „foo“ do streamu (napríklad do súboru)
// Krok 1. Vytvorte výstupný prúd
// to znamená, že vytvorte segment na príjem bajtov
FileOutputStream out = nový FileOutputStream ("fooFile");
// Krok 2. Vytvorte ObjectOutputStream
// to znamená, vytvorte hadicu a vložte jej hlavu do vedra
ObjectOutputStream os = nový ObjectOutputStream (out)
// Krok 3. Napíš reťazec a objekt do streamu
// to znamená nechať prúd prúdiť do vedra
os.writeObject ("foo");
os.writeObject (new Foo ());
// Krok 4. Vypláchnite údaje na miesto určenia
os.flush ();
The Writeobject metóda serializuje foo a jeho prechodné uzavretie - teda všetky objekty, na ktoré je možné v grafe odkazovať z foo. V rámci streamu existuje iba jedna kópia serializovaného objektu. Ostatné odkazy na objekty sú uložené ako úchytky objektov, aby sa ušetrilo miesto a zabránilo sa kruhovým odkazom. Serializovaný objekt začína triedou, za ktorou nasledujú polia každej triedy v hierarchii dedičstva.
// Čítanie objektu zo streamu
// Krok 1. Vytvorte vstupný prúd
FileInputStream in = nový FileInputStream ("fooFile");
// Krok 2. Vytvorte vstupný prúd objektu
ObjectInputStream ins = nový ObjectInputStream (v);
// Krok 3. Musím vedieť, čo čítate
String fooString = (Reťazec) ins.readObject ();
Foo foo = (Foo) s.readObject ();
Serializácia a bezpečnosť objektov
V predvolenom nastavení serializácia zapisuje a číta nestatické a nepriechodné polia z toku. Túto vlastnosť možno použiť ako bezpečnostný mechanizmus vyhlásením polí, ktoré sa nemôžu serializovať ako súkromné prechodné. Ak trieda nemusí byť vôbec serializovaná, writeObject a readObject metódy by mali byť implementované do hodu NoAccessException.
Perzistencia s transakčnou integritou: Predstavujeme JDBC
Po vzore X / Open SQL CLI (Client Level Interface) a Microsoft ODBC abstrakcií má Java database connectivity (JDBC) za cieľ poskytnúť mechanizmus pripojenia k databáze, ktorý je nezávislý od základného systému správy databáz (DBMS). Aby sa ovládače stali kompatibilnými s JDBC, je potrebné podporovať aspoň základné rozhranie API ANSI SQL-2, ktoré poskytuje predajcom nástrojov a aplikáciám tretích strán dostatočnú flexibilitu pre prístup k databáze.
JDBC je navrhnutý tak, aby bol konzistentný so zvyškom systému Java. Predajcom sa odporúča, aby napísali API, ktoré je typickejšie ako ODBC, čo umožňuje väčšiu statickú kontrolu typu v čase kompilácie.
Tu je popis najdôležitejších rozhraní JDBC:
java.sql.Driver.Managerspracováva načítanie ovládačov a poskytuje podporu pre nové pripojenia k databázam.java.sql.Connectionpredstavuje spojenie s konkrétnou databázou.java.sql.vyhláseniefunguje ako kontajner na vykonávanie príkazu SQL na danom pripojení.java.sql.ResultSetriadi prístup k množine výsledkov.
Ovládač JDBC môžete implementovať niekoľkými spôsobmi. Najjednoduchšie by bolo vytvoriť ovládač ako most k ODBC. Tento prístup je najvhodnejší pre nástroje a aplikácie, ktoré nevyžadujú vysoký výkon. Rozšíriteľnejšia konštrukcia by priniesla ďalšiu úroveň nepriamosti na server DBMS poskytnutím sieťového ovládača JDBC, ktorý pristupuje k serveru DBMS prostredníctvom zverejneného protokolu. Najefektívnejší ovládač by však mal priamy prístup k proprietárnemu API DBMS.
Objektové databázy a vytrvalosť v prostredí Java
Mnoho pretrvávajúcich projektov v priemysle ponúka vytrvalosť v prostredí Java na úrovni objektov. Avšak v čase písania tohto článku sú PSE (Persistent Storage Engine) a PSE Pro od spoločnosti Object Design jediné dostupné objektové databázové balíčky založené na Jave (prinajmenšom o nich viem). V sekcii Zdroje nájdete ďalšie informácie o programoch PSE a PSE Pro.
Vývoj v prostredí Java viedol k odklonu od tradičnej paradigmy vývoja dodávateľov softvéru, najmä v časovej osi vývojového procesu. Napríklad PSE a PSE Pro sú vyvíjané v heterogénnom prostredí. A pretože v procese vývoja neexistuje krok prepojenia, vývojári boli schopní vytvoriť rôzne funkčné komponenty nezávisle na sebe, čo vedie k lepšiemu a spoľahlivejšiemu objektovo orientovanému kódu.
Program PSE Pro má schopnosť obnoviť poškodenú databázu po prerušenej transakcii spôsobenej zlyhaním systému. Triedy, ktoré sú zodpovedné za túto pridanú funkčnosť, sa vo vydaní PSE nenachádzajú. Medzi týmito dvoma produktmi neexistujú žiadne ďalšie rozdiely. Týmto produktom hovoríme „dribbleware“ - softvérové vydania, ktoré vylepšujú ich funkčnosť pripojením nových komponentov. V nie príliš vzdialenej budúcnosti by sa koncept nákupu veľkého monolitického softvéru stal minulosťou. Nové obchodné prostredie v kyberpriestore spolu s výpočtovou technikou Java umožňujú používateľom nakupovať iba tie časti objektového modelu (objektový graf), ktoré potrebujú, čo vedie k kompaktnejším konečným produktom.
PSE funguje tak, že po vytvorení vývojárom súbory triedy post-processing a anotuje ich. Z hľadiska PSE sú triedy v objektovom grafe buď perzistentné, alebo perzistentné. Triedy s trvalou schopnosťou môžu pretrvávať samy, zatiaľ čo triedy s trvalým vedomím môžu pracovať s trvalými objektmi. Toto rozlíšenie je nevyhnutné, pretože vytrvalosť nemusí byť pre určité triedy požadovaným správaním. Postprocesor súboru triedy vykoná v triedach tieto úpravy:
