Objekta izturība vai neatlaidība, ir bieži dzirdētais termins, ko lieto kopā ar objektu glabāšanas datu bāzēs jautājumu. Paredzams, ka noturība darbosies ar darījumu integritāti, un kā tāda uz to attiecas stingri nosacījumi. (Plašāku informāciju par darījumu apstrādi skatiet šī raksta sadaļā Resursi.) Turpretī valodu pakalpojumos, kas tiek piedāvāti, izmantojot standarta valodu bibliotēkas un pakotnes, bieži vien nav darījumu ierobežojumu.
Kā redzēsim šajā rakstā, pierādījumi liecina, ka vienkārša Java noturība, visticamāk, izrietēs no pašas valodas, savukārt izsmalcinātu datu bāzes funkcionalitāti piedāvās datu bāzu piegādātāji.
Neviens objekts nav sala
Reālajā pasaulē jūs reti atrodat objektu, kuram nav attiecību ar citiem objektiem. Objekti ir objektu modeļi. Objekta ilgmūžības jautājums pārsniedz objekta modeļa izturības un izplatīšanas jautājumu, tiklīdz mēs izdarīsim novērojumu, ka objekti ir savstarpēji saistīti, pateicoties to savstarpējām attiecībām.
Relāciju pieeja datu glabāšanai mēdz apkopot datus pēc veida. Tabulas rindas attēlo tāda paša veida objektu fizisko kopumu diskā. Attiecības objektu starpā tiek attēlotas ar taustiņiem, kas tiek koplietoti daudzās tabulās. Lai gan, izmantojot datu bāzes organizāciju, relāciju datu bāzes dažkārt ļauj vienlaikus atrast tabulas, kuras, visticamāk, izmantos kopā (vai kopas) tajā pašā loģiskajā nodalījumā, piemēram, datu bāzes segmentā, viņiem nav mehānisma objektu attiecību glabāšanai datu bāzē. Tādējādi, lai izveidotu objekta modeli, šīs attiecības tiek konstruētas no esošajiem taustiņiem izpildes laikā procesā, kas tiek dēvēts par galds pievienojas. Šis ir tas pats pazīstamais relāciju datu bāzu īpašums datu neatkarība. Gandrīz visi objektu datu bāzu varianti piedāvā kādu mehānismu, lai uzlabotu sistēmas darbību, kas ietver sarežģītas objektu attiecības salīdzinājumā ar tradicionālajām relāciju datu bāzēm.
Vai vaicāt vai pārvietoties?
Uzglabājot objektus diskā, mēs esam izvēlējušies kopīgi atrast saistītus objektus, lai labāk pielāgotu navigācijas piekļuvi, vai glabāt objektus tabulām līdzīgās kolekcijās, kas objektus apkopo pēc veida, lai atvieglotu piekļuvi predikātiem (vaicājumiem) vai abiem. . Objektu vienlaicīga atrašanās vieta pastāvīgā krātuvē ir joma, kurā relāciju un objektorientētās datu bāzes ļoti atšķiras. Vēl viena uzmanības joma ir vaicājuma valodas izvēle. Strukturētā vaicājumu valoda (SQL) un tās paplašinājumi ir nodrošinājuši relāciju sistēmām piekļuves mehānismu, kura pamatā ir predikāts. Object Query Language (OQL) ir SQL objekta variants, ko standartizē ODMG, taču šīs valodas atbalsts pašlaik ir maz. Polimorfās metodes piedāvā nebijušu eleganci, veidojot semantisko vaicājumu objektu kolekcijai. Piemēram, iedomājieties polimorfu uzvedību rēķins sauca isInGoodStanding. Tas var atgriezt Būla vērtību true visiem kontiem ar labu reputāciju un nepatiesu citādi. Tagad iedomājieties eleganci vaicāt kontu kolekciju, kur inGoodStanding tiek ieviesta atšķirīgi, pamatojoties uz uzņēmējdarbības noteikumiem, visiem kontiem labā stāvoklī. Tas var izskatīties apmēram šādi:
setOfGoodCustomers = setOfAccounts.query (account.inGoodStanding ());
Kaut arī vairākas no esošajām objektu datu bāzēm spēj apstrādāt šādu vaicājuma stilu C ++ un Smalltalk, viņiem ir grūti to izdarīt lielākām (teiksim, 500+ gigabaitu) kolekcijām un sarežģītākām vaicājuma izteiksmēm. Vairāki no relāciju datu bāzu uzņēmumiem, piemēram, Oracle un Informix, drīz piedāvās citu, uz SQL balstītu sintaksi, lai sasniegtu to pašu rezultātu.
Noturība un veids
Uz objektu orientēts valodas entuziasts teiktu, ka noturība un tips ir objekta ortogonālās īpašības; tas ir, tāda paša veida pastāvīgi un pārejoši objekti var būt identiski, jo vienam īpašumam nevajadzētu ietekmēt otru. Alternatīvais viedoklis uzskata, ka noturība ir izturēšanās, kuru atbalsta tikai pastāvīgi objekti, un noteikta uzvedība var attiekties tikai uz pastāvīgiem objektiem. Pēdējā pieeja prasa metodes, kas uzdod pastāvīgajiem objektiem sevi uzglabāt un iegūt no pastāvīgas krātuves, savukārt pirmā nodrošina lietojumprogrammai nevainojamu visa objekta modeļa skatu - bieži vien paplašinot virtuālās atmiņas sistēmu.
Kanonizācija un valodas neatkarība
Viena tipa objekti valodā būtu jāuzglabā pastāvīgā krātuvē ar tādu pašu izkārtojumu neatkarīgi no to saskarnes secības. Procesi, kā objekta izkārtojumu pārveidot šajā kopējā formātā, kopā tiek saukti par objekta attēlojuma kanonizāciju. Kompilētās valodās ar statisko rakstīšanu (nevis Java) objektiem, kas rakstīti tajā pašā valodā, bet sastādīti dažādās sistēmās, pastāvīgā krātuvē jābūt identiski attēlotiem.
Kanonizācijas paplašinājums attiecas uz objektu attēlojumu, kas nav atkarīgs no valodas. Ja objektus var attēlot neatkarīgi no valodas, viena un tā paša objekta dažādiem attēlojumiem būs iespējams kopīgi izmantot vienu un to pašu pastāvīgo krātuvi.
Viens no šī uzdevuma izpildes mehānismiem ir ieviest papildu netiešo pakāpi, izmantojot interfeisa definīcijas valodu (IDL). Objektu datu bāzes saskarnes var izveidot, izmantojot IDL un atbilstošās datu struktūras. IDL stila saistījumu negatīvie aspekti ir divi: Pirmkārt, papildu netaisnības līmenim vienmēr ir nepieciešams papildu tulkošanas līmenis, kas ietekmē sistēmas kopējo veiktspēju; otrkārt, tas ierobežo tādu datu bāzes pakalpojumu izmantošanu, kas ir unikāli konkrētiem piegādātājiem un kuri varētu būt vērtīgi lietojumprogrammu izstrādātājiem.
Līdzīgs mehānisms ir objektu pakalpojumu atbalstīšana, izmantojot SQL paplašinājumu. Relatīvās datu bāzes piegādātāji un mazāki objektu / relāciju piegādātāji ir šīs pieejas atbalstītāji; tomēr vēl ir redzams, cik veiksmīgi šie uzņēmumi veidos objektu glabāšanas sistēmu.
Bet jautājums paliek: vai objekta noturība ir daļa no objekta uzvedības, vai tas ir ārējs pakalpojums, kas tiek piedāvāts objektiem, izmantojot atsevišķas saskarnes? Kā būtu ar objektu kolekcijām un metodēm to vaicāšanai? Relāciju, paplašināto relāciju un objektu / relāciju pieejas mēdz atbalstīt valodas nošėiršanu, savukārt objektu datubāzes - un pati Java valoda - noturību uzskata par valodas būtību.
Vietējā Java noturība, izmantojot serializāciju
Objekta serializācija ir Java valodai raksturīgs mehānisms Java objektu un primitīvu glabāšanai un atgūšanai straumēs. Ir vērts atzīmēt, ka, lai gan komerciālas trešo pušu bibliotēkas C ++ objektu serializēšanai ir zināmas jau kādu laiku, C ++ nekad nav piedāvājis vietējo mehānismu objektu serializēšanai. Lūk, kā izmantot Java serializāciju:
// "foo" rakstīšana straumē (piemēram, failā)
// 1. solis. Izveidojiet izvades straumi
// tas ir, izveidojiet kausu, lai saņemtu baitus
FileOutputStream out = jauns FileOutputStream ("fooFile");
// 2. solis. Izveidojiet ObjectOutputStream
// tas ir, izveidojiet šļūteni un ielieciet galvu spainī
ObjectOutputStream os = jauns ObjectOutputStream (out)
// 3. solis. Uzrakstiet straumē virkni un objektu
// tas ir, ļaujiet straumei ieplūst spainī
os.writeObject ("foo");
os.writeObject (jauns Foo ());
// 4. solis. Izskalojiet datus līdz galamērķim
os.skalot ();
The Writeobject metode serializē foo un tā tranzitīvo slēgšanu, tas ir, visus objektus, uz kuriem grafikā var atsaukties no foo. Straumē eksistē tikai viena sērijveida objekta kopija. Citas atsauces uz objektiem tiek saglabātas kā objektu rokturi, lai ietaupītu vietu un izvairītos no apļveida atsaucēm. Serializētais objekts sākas ar klasi, kam seko katras klases lauki mantojuma hierarhijā.
// Objekta lasīšana no straumes
// 1. solis. Izveidojiet ievades straumi
FileInputStream in = jauns FileInputStream ("fooFile");
// 2. solis. Izveidojiet objekta ievades straumi
ObjectInputStream ins = jauns ObjectInputStream (in);
// 3. solis. Jāzina, ko lasāt
String fooString = (String) ins.readObject ();
Foo foo = (Foo) s.readObject ();
Objekta serializācija un drošība
Pēc noklusējuma sērijveidošana no straumes raksta un nolasa ne statiskus un nepārejošus laukus. Šo raksturlielumu var izmantot kā drošības mehānismu, deklarējot laukus, kas var nebūt seriālizēti, kā privātus pārejošus. Ja klasi vispār nevar seriālizēt, writeObject un lasīt objektu jāievieš metināšanas metodes NoAccessException.
Noturība ar darījumu integritāti: Iepazīstinām ar JDBC
Modelējot pēc X / Open SQL CLI (klienta līmeņa saskarnes) un Microsoft ODBC abstrakcijām, Java datu bāzes savienojamības (JDBC) mērķis ir nodrošināt datu bāzes savienojamības mehānismu, kas nav atkarīgs no pamata datu bāzes pārvaldības sistēmas (DBVS). Lai kļūtu saderīgi ar JDBC, draiveri jāatbalsta vismaz ANSI SQL-2 sākuma līmeņa API, kas trešo pušu rīku piegādātājiem un lietojumprogrammām nodrošina pietiekamu elastību piekļuvei datu bāzēm.
JDBC ir veidots tā, lai būtu saderīgs ar pārējo Java sistēmu. Pārdevēji tiek aicināti rakstīt API, kas ir stingrāk ierakstīts nekā ODBC, kas nodrošina lielāku statiskā tipa pārbaudi sastādīšanas laikā.
Šeit ir vissvarīgāko JDBC saskarņu apraksts:
java.sql.Driver.Managerveic draiveru ielādi un nodrošina atbalstu jauniem datu bāzes savienojumiem.java.sql.Savienojumsapzīmē savienojumu ar noteiktu datu bāzi.java.sql.Statementdarbojas kā konteiners SQL priekšraksta izpildei dotajā savienojumā.java.sql.ResultSetkontrolē piekļuvi rezultātu kopai.
JDBC draiveri var ieviest vairākos veidos. Vienkāršākais būtu vadītāju uzbūvēt kā tiltu uz ODBC. Šī pieeja ir vislabāk piemērota rīkiem un lietojumprogrammām, kurām nav nepieciešama augsta veiktspēja. Paplašināmāks dizains ieviesīs papildu neticības līmeni DBVS serverim, nodrošinot JDBC tīkla draiveri, kas piekļūst DBVS serverim, izmantojot publicētu protokolu. Visefektīvākais draiveris tomēr tieši piekļūtu DBVS patentētajam API.
Objekta datu bāzes un Java noturība
Vairāki nozarē notiekošie projekti piedāvā Java noturību objekta līmenī. Tomēr, sākot ar šo rakstu, Object Design's PSE (Persistent Storage Engine) un PSE Pro ir vienīgās pieejamās pilnībā Java balstītas, objektorientētas datu bāzes paketes (vismaz par kurām es esmu informēts). Lai iegūtu papildinformāciju par PSE un PSE Pro, skatiet sadaļu Resursi.
Java izstrāde ir novedusi pie novirzes no tradicionālās programmatūras pārdevēju attīstības paradigmas, it īpaši izstrādes procesa grafikā. Piemēram, PSE un PSE Pro tiek izstrādāti neviendabīgā vidē. Tā kā izstrādes procesā nav sasaistes posma, izstrādātāji ir spējuši izveidot dažādus funkcionālus komponentus neatkarīgi viens no otra, kā rezultātā tiek iegūts labāks, uzticamāks objektorientēts kods.
PSE Pro spēj atgūt bojātu datu bāzi no pārtraukta darījuma, ko izraisījusi sistēmas kļūme. Klases, kas ir atbildīgas par šo pievienoto funkcionalitāti, nav PSE laidienā. Starp šiem diviem produktiem nav citu atšķirību. Šos produktus mēs saucam par "dribbleware" - programmatūras izlaidumiem, kas uzlabo to funkcionalitāti, pievienojot jaunus komponentus. Ne tik tālā nākotnē lielas monolītas programmatūras iegādes koncepcija kļūtu par pagātni. Jaunā biznesa vide kibertelpā kopā ar Java skaitļošanu ļauj lietotājiem iegādāties tikai tās objekta modeļa daļas (objekta grafiku), kas viņiem nepieciešams, kā rezultātā tiek iegūti kompaktāki galaprodukti.
PSE darbojas pēcapstrādē un anotējot klases failus pēc tam, kad izstrādātājs tos ir izveidojis. No PSE viedokļa objekta diagrammas klases ir vai nu noturīgas, vai pastāvīgi informētas. Pastāvīgi spējīgas klases var pastāvēt pašas, kamēr pastāvīgi informētas klases var darboties ar pastāvīgiem objektiem. Šī atšķirība ir nepieciešama, jo noturība dažām klasēm var nebūt vēlama rīcība. Klases faila pēcapstrādātājs klasēs veic šādas izmaiņas:
