Корпоративните приложения често се занимават с операции като събиране, обработка, трансформиране и отчитане на голямо количество данни. Тези данни обикновено се съхраняват в сървър на база данни на определено място и се извличат при поискване. Приложението е отговорно за обработката на данните от базата данни и накрая ги представя за потребителска употреба. Но тънкостите, свързани с смекчаването на обмена на данни между различните архитектури, са истинското предизвикателство, пред което са изправени разработчиците. Сърцето на проблема се крие в облекчаването на сложната връзка на движението на данни между кода, използван за разработване на приложението, и модела за съхранение, използван за запазване на данните. Накратко, идеята е да се създаде механизъм за безпроблемно взаимодействие между два непоколебими модела:обектно-ориентираната природа на езика Java и модела на релационна база данни.
Основни API за бази данни
Платформата Java вече има стандартни API за работа със системи от бази данни под формата на JDBC API. Тези API са отлични при работа с базата данни и предоставят средствата, необходими за удобно взаимодействие с базата данни от езика Java. Но проблемът е, че Java е обектно-ориентиран език. JDBC предоставя основни API за взаимодействие с база данни и не е фокусиран върху трансформирането на структурата на редове и колони на таблицата на базата данни в клас обект. Следователно се търси слой от API, който работи над JDBC API. API за постоянство, или JPA, смекчава два архитектурно различни модела с цел да се използва плавността на работа. API помага да се представи таблица за връзки на база данни като POJO и може да се третира по подобен начин чрез Java код. Основният JDBC API работи във фонов режим, за да се справи с тънкостите на комуникацията и връзката с база данни, докато JPA позволява работата да се извършва според обектно-ориентирания код на езика Java. Въпреки това, картографирането на данни между релационна база данни и Java не е лесна задача.
Поддръжка за постоянство на Java
В типична релационна база данни информацията се съхранява в структура от редове и колони. Обменът на данни между система от база данни и обектния модел на приложението Java е труден, тъй като Java обозначава един обект като клас, обозначен с набор от свойства и операции, приложени към тях. Следователно, за да съобрази поведенческото несъответствие между двете различни архитектури, Java програмист трябва да напише много редове код. Тези редове код помагат да се трансформират данните от редовете и колоните на таблицата на базата данни в Java обекти. Но често тези редове код стават твърде повтарящи се, което води до изходния код, пълен с шаблонни кодове. Това е нежелателно и нарушава основния обектно-ориентиран принцип за повторна употреба. Въпреки че умните кодове могат да смекчат много от неприятностите, това не е лесно решение. Появата на решения на трети страни е почивка в картографирането на данни от база данни в Java обекти, но те не бяха стандартни. Всяка реализация на доставчик се различава значително от друга. Всичко това означава, че ситуацията изисква стандартна постоянна API библиотека от самата платформа Java. Това доведе до въвеждането на Java Persistence API (JPA), особено за преодоляване на пропастта между обектно-ориентирания домейн модел на Java и системата на базата данни.
Собствени решения
Разберете, че обективно-релационните решения съществуват от доста време, датиращи още преди раждането на самия език Java. Например, продуктът TopLink на Oracle всъщност стартира с Smalltalk, а след това по-късно премина към Java. Днес той е част от сървърите OracleAS, WebLogic и OC4J. Всъщност двата най-популярни API за постоянство са били TopLink на Oracle, собствен стандарт в търговския домейн, и Hibernate в домейна на общността с отворен код. По-късно Hibernate стана по-популярен и силно повлия върху създаването на стандартната библиотека JPA.
Картографи на данни
Картографът на данни е основно архитектурен модел, предложен от Мартин Фаулър в неговата книга Модели на архитектурата на корпоративните приложения , 2003. Той предоставя частичен начин за справяне с обектно-релационния проблем. Картографът помага за създаването на стратегия, която попада в категорията между обикновен JDBC и пълнофункционално решение за релационно картографиране на обекти. Тук разработчиците на приложения създават необработен SQL низ, за да съпоставят таблици на база данни с Java обекти, като използват метода за картографиране на данни. Има популярна рамка, която използва тази техника за съпоставяне между SQL база данни и Java обект, наречена Apache iBatis. Проектът Apache iBatis сега е обявен за неактивен. Въпреки това, първоначалните създатели на Apache iBatis са прехвърлили проекта в MyBatis и е в процес на активно развитие.
За разлика от други обектно-релационни решения на проблеми, използващи рамката за картографиране на данни като MyBatis, ние можем да имаме пълен контрол върху SQL транзакциите с базата данни. Това е леко решение и не носи режийните разходи за пълноценна ORM рамка. Но има проблем с картографите на данни. Всички промени, направени в обектния модел, имат отражение върху модела на данните. Човек трябва да направи значителни промени в SQL изразите директно като следствие. Минималистичният характер на рамката помага на разработчиците да включат нови промени и модификации според нуждите. Преобразувателите на данни са особено полезни в ситуация, в която се нуждаем от минимална рамка, изрична обработка на SQL и повече контрол за промяна на разработчиците.
JDBC
JDBC (Java Database Connectivity) е специфична за Java версия на спецификацията на Microsoft ODBC (Object Database Connectivity). ODBC е стандарт за свързване на всяка релационна база данни от всеки език или платформа. JDBC предоставя подобна абстракция по отношение на езика Java. JDBC използва SQL за взаимодействие с базата данни. Разработчиците трябва да пишат DDL или DML заявки според синтактичната спецификация на бекенд базата данни, но да ги обработват с помощта на модела за програмиране на Java. Съществува тясна връзка между източника на Java и SQL изразите. Можем да прибягваме до необработени SQL изрази и да ги манипулираме статично според нуждите. Поради статичния му характер е трудно да се включат промени. Освен това, SQL диалектите варират от един доставчик на база данни до друг. JDBC е свързан хардуерно към базата данни, а не към обектния модел на езика Java. Поради това скоро ще се почувства тромаво за работа, особено когато се увеличи взаимодействието с база данни от изходния код на Java. JDBC обаче е основната поддръжка за устойчивост на база данни в Java и формира основата за рамки на високо ниво.
EJB
Enterprise Java Bean (EJB) с J2EE донесе някои нови промени в областта на устойчивостта на Java под формата на entity bean. Идеята беше да се изолират разработчиците от пряка намеса в тънкостите на постоянството на базата данни. Той въведе подход, базиран на интерфейс. Има специализиран компилатор на bean за генериране на имплементацията за постоянство, управление на транзакции и делегиране на бизнес логика. Специализирани дескриптори за разгръщане на XML бяха използвани за конфигуриране на бибовете на обекта. Проблемът е, че EJB, вместо да опростява нещата, включва много сложност. В резултат на това, въпреки множеството последващи подобрения, като въвеждането на Enterprise JavaBeans Query Language (EJB QL), той скоро загуби популярност.
Обект с данни на Java
JDO (Java Data Object) се опита да се справи с проблема, пред който е изправен моделът за постоянство на EJB. Той предоставя API за прозрачна устойчивост и е проектиран да работи с EJB и J2EE. JDO е продукт, силно повлиян и поддържан от обектно-ориентирани бази данни. Постоянните обекти са обикновени Java обекти, които не изискват от разработчик да имплементира специален клас или интерфейс. Спецификациите за постоянство на обекта обикновено се дефинират в XML метафайл. Поддържаните езици за заявки са обектно-ориентирани по природа. Въпреки многото добри характеристики, спецификацията на JDO не можа да грабне голямо одобрение сред общността на разработчиците.
API за постоянство на Java
Имаше редица собствени рамки за постоянство както в търговския домейн, така и в домейна с отворен код. Рамки като Hibernate и TopLink изглежда отговаряха доста добре на нуждите на приложението. В резултат на това Hibernate беше избран като основна основа за създаване на стандартен модел на постоянство, наречен JPA.
JPA е стандартна лека рамка за постоянство на Java, която помага за създаване на релационно картографиране на обекти с помощта на POJO. JPA също така помага за интегрирането на постоянството в мащабируемо корпоративно приложение. Той е лесен за използване, защото има само малък брой класове, които трябва да бъдат изложени на приложение, което се интересува от използването на модела за постоянство на JPA. Използването на POJO е може би най-интригуващият аспект на JPA. Това означава, че няма нищо специално за обекта; което го прави устойчив. Обектно-релационното картографиране се управлява от метаданни. Това може да се направи или чрез използване на анотация вътрешно в кода или външно. чрез използване на XML.
Постоянните API на JPA съществуват като отделен слой от постоянния обект. Бизнес логиката обикновено извиква API и предава постоянния обект, за да оперира с тях. Въпреки че приложението е наясно с постоянния API, постоянният обект, който е POJO, напълно не е наясно с неговата способност за постоянство.
Заключение
Тази статия направи преглед на някои от патентованите решения, налични преди въвеждането на JPA, като например картографиране на данни, JDBC и EJB. Идеята е да се даде представа за това, което доведе до създаването на JPA, и малко за постоянната техника на предшественика му. Останете на линия; следващите статии се задълбочават в по-специфични аспекти на API на JPA.
