Постоянство на обекта и Java

Трайността на обекта или постоянството е терминът, който често чувате, използван заедно с въпроса за съхраняването на обекти в бази данни. Очаква се постоянството да работи с транзакционна цялост и като такова е подчинено на строги условия. (За повече информация относно обработката на транзакции вижте раздела „Ресурси“ на тази статия.) За разлика от това, езиковите услуги, предлагани чрез стандартни езикови библиотеки и пакети, често са свободни от транзакционни ограничения.

Както ще видим в тази статия, доказателствата сочат, че обикновената устойчивост на Java вероятно ще произтича от самия език, докато сложната функционалност на базата данни ще се предлага от доставчици на бази данни.

Никой обект не е остров

В реалния свят рядко срещате обект, който няма връзки с други обекти. Обектите са компоненти на обектните модели . Въпросът за дълготрайността на обекта надхвърля въпроса за трайността и разпределението на обектния модел, след като направим наблюдението, че обектите са взаимосвързани по силата на техните отношения помежду си.

Релационният подход за съхранение на данни има тенденция към обобщаване на данни по тип. Редовете в таблица представляват физическата съвкупност от обекти от същия тип на диска. Тогава връзките между обектите се представят от ключове, които се споделят в много таблици. Въпреки че чрез организация на база данни, релационните бази данни понякога позволяват таблици, които е вероятно да бъдат използвани заедно, да бъдат разположени (или групирани ) в един и същ логически дял, като сегмент на база данни, те нямат механизъм за съхраняване на обектни връзки в базата данни. Следователно, за да се изгради обектен модел, тези връзки се изграждат от съществуващите ключове по време на изпълнение в процес, посочен като обединения на таблици . Това е същото познато свойство на релационните бази данни, нареченонезависимост на данните . Почти всички варианти на обектни бази данни предлагат някакъв механизъм за подобряване на производителността на система, която включва сложни обектни връзки спрямо традиционните релационни бази данни.

Запитване или навигация?

При съхраняването на обекти на диск, ние сме изправени пред избора за съвместно локализиране на свързани обекти, за да се приспособи по-добре навигационният достъп или да се съхраняват обекти в подобни на таблици колекции, които обединяват обекти по тип, за да улеснят достъпа въз основа на предикати (заявки), или и двете . Колокацията на обектите в постоянното съхранение е област, в която релационните и обектно-ориентираните бази данни се различават значително. Изборът на езика на заявката е друга област на разглеждане. Структурираният език за заявки (SQL) и разширенията му осигуряват релационни системи с механизъм за достъп, базиран на предикати. Обектният език за заявки (OQL) е обектен вариант на SQL, стандартизиран от ODMG, но в момента поддръжката за този език е оскъдна. Полиморфните методи предлагат безпрецедентна елегантност при изграждането на семантична заявка за колекция от обекти. Например,представете си полиморфно поведение заacccountсе обади isInGoodStanding. Той може да върне логическото true за всички акаунти в добро състояние, и false в противен случай. Сега си представете елегантността на заявките за събиране на сметки, където inGoodStandingсе прилага по различен начин въз основа на бизнес правилата, за всички акаунти в добро състояние. Може да изглежда по следния начин:

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

Въпреки че няколко от съществуващите обектни бази данни могат да обработват такъв стил на заявка в C ++ и Smalltalk, за тях е трудно да го направят за по-големи (да речем, 500+ гигабайта) колекции и по-сложни изрази на заявки. Няколко от компаниите за релационни бази данни, като Oracle и Informix, скоро ще предложат друг, базиран на SQL синтаксис, за да постигнат същия резултат.

Постоянство и вид

Любителят на обектно-ориентирания език би казал, че постоянството и типът са ортогонални свойства на обекта; т.е. постоянни и преходни обекти от един и същи тип могат да бъдат идентични, тъй като едното свойство не трябва да влияе върху другото. Алтернативният изглед твърди, че постоянството е поведение, поддържано само от постоянни обекти и определено поведение може да се прилага само за постоянни обекти. Последният подход изисква методи, които инструктират постоянни обекти да се съхраняват и извличат от постоянно съхранение, докато първият предоставя на приложението безпроблемен изглед на целия обектен модел - често чрез разширяване на системата за виртуална памет.

Канонизация и езикова независимост

Обектите от един и същи тип на даден език трябва да се съхраняват в постоянни хранилища с едно и също оформление, независимо от реда, в който се появяват техните интерфейси. Процесите на трансформиране на обектно оформление в този общ формат са общо известни като канонизиране на представяне на обект. В компилираните езици със статично типизиране (не Java) обектите, написани на един и същ език, но компилирани под различни системи, трябва да бъдат идентично представени в постоянното съхранение.

Разширение на канонизацията адресира независимо от езика представяне на обект. Ако обектите могат да бъдат представени по независим от езика начин, ще бъде възможно различни представяния на един и същ обект да споделят едно и също постоянно съхранение.

Един механизъм за изпълнение на тази задача е да се въведе допълнително ниво на непрякост чрез език за дефиниране на интерфейс (IDL). Интерфейсите на базата обекти могат да бъдат направени чрез IDL и съответните структури от данни. Недостатъкът на обвързването в стил IDL е два пъти: Първо, допълнителното ниво на индирекция винаги изисква допълнително ниво на превод, което влияе върху цялостната производителност на системата; второ, ограничава използването на услуги за бази данни, които са уникални за конкретни доставчици и които могат да бъдат ценни за разработчиците на приложения.

Подобен механизъм е да поддържа обектни услуги чрез разширение на SQL. Доставчиците на релационни бази данни и по-малките обектни / релационни доставчици са привърженици на този подход; обаче колко успешни ще бъдат тези компании при оформянето на рамката за съхранение на обекти, предстои да разберем.

Но въпросът остава: Устойчивостта на обекта част ли е от поведението на обекта или е външна услуга, предлагана на обекти чрез отделни интерфейси? Какво ще кажете за колекции от обекти и методи за тяхното заявяване? Релационните, разширените релационни и обектно / релационните подходи са склонни да защитават разделянето между езика, докато обектните бази данни - и самият език Java - виждат постоянството като присъщо за езика.

Постоянство на родната Java чрез сериализация

Обектната сериализация е специфичен за езика механизъм Java за съхранение и извличане на Java обекти и примитиви в потоци. Заслужава да се отбележи, че въпреки че търговски библиотеки на трети страни за сериализиране на C ++ обекти съществуват от известно време, C ++ никога не е предлагал собствен механизъм за сериализация на обекти. Ето как да използвате сериализацията на Java:

// Записване на "foo" в поток (например файл)

// Стъпка 1. Създайте изходен поток

// т.е. създайте кофа за получаване на байтовете

FileOutputStream out = нов FileOutputStream ("fooFile");

// Стъпка 2. Създаване на ObjectOutputStream

// т.е. създайте маркуч и поставете главата му в кофата

ObjectOutputStream os = нов ObjectOutputStream (навън)

// Стъпка 3. Напишете низ и обект в потока

// т.е. оставете потока да се влее в кофата

os.writeObject ("foo");

os.writeObject (нов Foo ());

// Стъпка 4. Измийте данните до местоназначението им

os.flush ();

В Writeobjectметода serializes Фу и преходен затваряне - това е, всички обекти, които могат да бъдат отнесени от Фу в графиката. В потока съществува само едно копие на сериализирания обект. Други препратки към обектите се съхраняват като манипулатори на обекти, за да се спести място и да се избегнат кръгови препратки. Сериализираният обект започва с класа, последван от полетата на всеки клас в йерархията на наследяване.

// Четене на обект от поток

// Стъпка 1. Създайте входен поток

FileInputStream в = нов FileInputStream ("fooFile");

// Стъпка 2. Създаване на обект входящ поток

ObjectInputStream ins = нов ObjectInputStream (в);

// Стъпка 3. Трябва да разберете какво четете

Низ fooString = (низ) ins.readObject ();

Foo foo = (Foo) s.readObject ();

Сериализация на обекти и сигурност

По подразбиране сериализацията записва и чете нестатични и нетрайни полета от потока. Тази характеристика може да се използва като защитен механизъм чрез деклариране на полета, които не могат да бъдат сериализирани като частни преходни. Ако даден клас изобщо не може да бъде сериализиран writeObjectи readObjectтрябва да се внедрят методи за хвърляне NoAccessException.

Постоянство с транзакционна цялост: Представяне на JDBC

Моделирана след SQL CLI на X / Open (Client Level Interface) и ODBC абстракции на Microsoft, свързването на базата данни Java (JDBC) има за цел да осигури механизъм за свързване на база данни, който е независим от основната система за управление на база данни (СУБД). За да станат съвместими с JDBC, драйверите трябва да поддържа поне API за входно ниво на ANSI SQL-2, който предоставя на доставчиците на приложения и приложения на трети страни достатъчно гъвкавост за достъп до база данни.

JDBC е проектиран да бъде в съответствие с останалата част от системата Java. Доставчиците се насърчават да напишат API, който е по-силно типизиран от ODBC, който осигурява по-голяма статична проверка на типа по време на компилация.

Ето описание на най-важните JDBC интерфейси:

  • java.sql.Driver.Manager обработва зареждането на драйвери и осигурява поддръжка за нови връзки с база данни.

  • java.sql.Connection представлява връзка към определена база данни.

  • java.sql.Statement действа като контейнер за изпълнение на SQL израз на дадена връзка.

  • java.sql.ResultSet контролира достъпа до резултата.

Можете да внедрите JDBC драйвер по няколко начина. Най-простото би било да се изгради драйверът като мост към ODBC. Този подход е най-подходящ за инструменти и приложения, които не изискват висока производителност. По-разширяващият се дизайн би въвел допълнително ниво на непрякост към сървъра на СУБД, като осигури мрежов драйвер JDBC, който осъществява достъп до СУБД сървъра чрез публикуван протокол. Най-ефективният драйвер обаче ще има директен достъп до собствения API на СУБД.

Бази данни на обекти и устойчивост на Java

Редица текущи проекти в индустрията предлагат устойчивост на Java на обектно ниво. Към момента на писането обаче PSE (Persistent Storage Engine) и PSE Pro на Object Design са единствените напълно базирани на Java, обектно-ориентирани пакети от бази данни (поне това, което съм наясно). Проверете раздела Ресурси за повече информация относно PSE и PSE Pro.

Разработването на Java доведе до отклонение от традиционната парадигма за разработчици на доставчици на софтуер, най-вече в графика на процеса на разработка. Например PSE и PSE Pro са разработени в хетерогенна среда. И тъй като в процеса на разработка няма свързваща стъпка, разработчиците са успели да създадат различни функционални компоненти, независими един от друг, което води до по-добър, по-надежден обектно-ориентиран код.

PSE Pro има способността да възстановява повредена база данни от прекъсната транзакция, причинена от системна повреда. Класовете, които са отговорни за тази добавена функционалност, не присъстват в PSE версията. Не съществуват други разлики между двата продукта. Тези продукти са това, което наричаме „дрибъл софтуер“ - софтуерни версии, които подобряват тяхната функционалност чрез включване на нови компоненти. В не толкова далечното бъдеще концепцията за закупуване на голям, монолитен софтуер ще се превърне в минало. Новата бизнес среда в киберпространството, заедно с изчисленията на Java, позволяват на потребителите да купуват само онези части от обектния модел (обектна графика), от които се нуждаят, което води до по-компактни крайни продукти.

PSE работи чрез последваща обработка и анотиране на файлове на класа, след като са създадени от разработчика. От гледна точка на PSE, класовете в обектната графика са или устойчиви, или постоянни. Устойчивите класове могат да продължат да съществуват, докато устойчивите класове могат да работят върху устойчиви обекти. Това разграничение е необходимо, защото постоянството може да не е желано поведение за определени класове. Следпроцесорът на файла на класа прави следните модификации на класовете: