Aplikacje korporacyjne często zajmują się operacjami, takimi jak zbieranie, przetwarzanie, przekształcanie i raportowanie dużej ilości danych. Dane te są zwykle przechowywane na serwerze bazy danych w określonej lokalizacji i pobierane na żądanie. Aplikacja odpowiada za przetwarzanie danych z bazy danych i finalnie prezentację ich do konsumpcji przez klienta. Jednak zawiłości związane z ograniczaniem wymiany danych między różnymi architekturami są prawdziwym wyzwaniem, przed którym stoją programiści. Sedno problemu tkwi w złagodzeniu skomplikowanej relacji przenoszenia danych między kodem użytym do opracowania aplikacji a modelem pamięci używanym do trwałości danych. Krótko mówiąc, chodzi o stworzenie mechanizmu bezproblemowej interakcji między dwoma nieustępliwymi modelami:obiektową naturą języka Java i relacyjnym modelem bazy danych.
Podstawowe interfejsy API dla baz danych
Platforma Java posiada już standardowe API do pracy z systemami bazodanowymi w postaci API JDBC. Te interfejsy API doskonale sprawdzają się w pracy z bazą danych i zapewniają środki niezbędne do wygodnej interakcji z bazą danych z poziomu języka Java. Problem polega jednak na tym, że Java jest językiem zorientowanym obiektowo. JDBC udostępnia podstawowe interfejsy API do interakcji z bazą danych i nie koncentruje się na przekształcaniu struktury wierszy i kolumn tabeli bazy danych w klasę jednostki. Dlatego poszukuje się warstwy API, która działa ponad API JDBC. Interfejs API trwałości (JPA) łagodzi dwa różne architektonicznie modele w celu wykorzystania płynności działania. Interfejs API pomaga reprezentować tabelę relacji bazy danych jako POJO i może być traktowany w podobny sposób w całym kodzie Java. Podstawowe API JDBC działa w tle, aby radzić sobie ze zawiłościami komunikacji i połączenia z bazą danych, podczas gdy JPA umożliwia wykonywanie operacji zgodnie z kodem obiektowym języka Java. Jednak mapowanie danych między relacyjną bazą danych a Javą nie jest łatwym zadaniem.
Obsługa trwałości Java
W typowej relacyjnej bazie danych informacje są przechowywane w strukturze wierszowej i kolumnowej. Wymiana danych między systemem bazodanowym a modelem obiektowym aplikacji Java jest trudna, ponieważ Java wyznacza pojedynczą jednostkę jako klasę oznaczaną przez zestaw właściwości i zastosowanych na nich operacji. Dlatego też, aby zapewnić zgodność behawioralną między dwiema różnymi architekturami, programista Java musi napisać wiele wierszy kodu. Te wiersze kodu pomagają przekształcić dane wierszy i kolumn tabeli bazy danych na obiekty Java. Jednak często te wiersze kodu stają się zbyt powtarzalne, co powoduje, że kod źródłowy jest przepełniony kodami standardowymi. Jest to niepożądane i narusza podstawową zasadę wielokrotnego użytku zorientowaną obiektowo. Chociaż sprytne kody mogą złagodzić wiele przeciwności, nie jest to łatwe rozwiązanie. Pojawienie się rozwiązań firm trzecich jest wytchnieniem w mapowaniu danych bazodanowych na obiekty Java, ale nie były one standardowe. Każde wdrożenie dostawcy różniło się znacznie od drugiego. To wszystko oznacza, że sytuacja wymagała standardowej biblioteki API trwałości od samej platformy Java. Doprowadziło to do wprowadzenia Java Persistence API (JPA), zwłaszcza w celu wypełnienia luki między obiektowym modelem domeny Java a systemem baz danych.
Zastrzeżone rozwiązania
Zrozum, że rozwiązania obiektowo-relacyjne istnieją już od dłuższego czasu, sięgając nawet przed narodzinami samego języka Java. Na przykład produkt TopLink firmy Oracle faktycznie rozpoczął się od Smalltalk, a następnie przeszedł na Javę. Dziś jest częścią serwerów OracleAS, WebLogic i OC4J. W rzeczywistości dwoma najpopularniejszymi interfejsami API trwałości były kiedyś Oracle TopLink, zastrzeżony standard w domenie komercyjnej, oraz Hibernate w domenie społeczności open source. Później Hibernate stał się bardziej popularny i mocno wpłynął na stworzenie standardowej biblioteki JPA.
Mapy danych
Maper danych to w zasadzie wzorzec architektoniczny zaproponowany przez Martina Fowlera w jego książce Wzorce architektury aplikacji korporacyjnych , 2003. Zapewnia częściowy sposób rozwiązania problemu obiektowo-relacyjnego. Mapper pomaga stworzyć strategię, która należy do kategorii między zwykłym JDBC a w pełni funkcjonalnym rozwiązaniem mapowania relacyjnego obiektów. W tym przypadku programiści aplikacji tworzą nieprzetworzony ciąg SQL, aby mapować tabele bazy danych na obiekty Java za pomocą metody mapowania danych. Istnieje popularny framework, który wykorzystuje tę technikę mapowania między bazą danych SQL a obiektem Java, zwany Apache iBatis. Projekt Apache iBatis został uznany za nieaktywny. Jednak pierwotni twórcy Apache iBatis przenieśli projekt do MyBatis i jest aktywnie rozwijany.
W przeciwieństwie do innych rozwiązań problemów obiektowo-relacyjnych wykorzystujących framework mapowania danych, takich jak MyBatis, możemy mieć pełną kontrolę nad transakcjami SQL z bazą danych. Jest to lekkie rozwiązanie i nie obciąża całościowego frameworka ORM. Ale jest problem z mapowaniem danych. Wszelkie zmiany wprowadzone w modelu obiektowym mają wpływ na model danych. W konsekwencji należy bezpośrednio wprowadzić znaczące zmiany w instrukcjach SQL. Minimalistyczny charakter frameworka pomaga programistom wprowadzać nowe zmiany i modyfikacje zgodnie z potrzebami. Mapery danych są szczególnie przydatne w sytuacji, gdy potrzebujemy minimalnego frameworka, wyraźnej obsługi SQL i większej kontroli nad modyfikacją programistów.
JDBC
JDBC (Java Database Connectivity) to specyficzna dla języka Java wersja specyfikacji ODBC (Object Database Connectivity) firmy Microsoft. ODBC to standard łączenia dowolnej relacyjnej bazy danych z dowolnego języka lub platformy. JDBC zapewnia podobną abstrakcję w odniesieniu do języka Java. JDBC używa SQL do interakcji z bazą danych. Deweloperzy muszą pisać zapytania DDL lub DML zgodnie ze specyfikacją składniową bazy danych zaplecza, ale przetwarzają je przy użyciu modelu programowania Java. Istnieje ścisłe powiązanie między źródłem Java a instrukcjami SQL. Możemy odwoływać się do surowych instrukcji SQL i manipulować nimi statycznie w zależności od potrzeb. Ze względu na swój statyczny charakter trudno wprowadzić zmiany. Co więcej, dialekty SQL różnią się w zależności od dostawcy bazy danych. JDBC jest powiązany z bazą danych, a nie z modelem obiektowym języka Java. Dlatego wkrótce praca z nią staje się kłopotliwa, zwłaszcza gdy wzrasta interakcja z bazą danych z kodu źródłowego Java. Jednak JDBC jest podstawową obsługą trwałości bazy danych w Javie i stanowi podstawę dla frameworków wysokiego poziomu.
EJB
Enterprise Java Bean (EJB) z J2EE przyniósł kilka nowych zmian na arenie trwałości Javy w postaci fasoli encji. Pomysł polegał na odizolowaniu programistów od bezpośredniej ingerencji w zawiłości trwałości bazy danych. Wprowadził podejście oparte na interfejsie. Istnieje wyspecjalizowany kompilator komponentów bean do generowania implementacji na potrzeby trwałości, zarządzania transakcjami i delegowania logiki biznesowej. Do konfiguracji ziaren encji użyto wyspecjalizowanych deskryptorów wdrażania XML. Problem polega na tym, że EJB, zamiast upraszczać rzeczy, zawiera dużo złożoności. W rezultacie, pomimo licznych późniejszych ulepszeń, takich jak wprowadzenie Enterprise JavaBeans Query Language (EJB QL), szybko stracił popularność.
Obiekt danych Java
JDO (Java Data Object) próbował rozwiązać problem, z którym borykał się model trwałości EJB. Zapewnia interfejs API zapewniający transparentną trwałość i jest przeznaczony do pracy z EJB i J2EE. JDO to produkt, na który duży wpływ ma i jest wspierany przez bazy danych zorientowanych obiektowo. Obiekty trwałe to zwykłe obiekty Java, które nie wymagają od programisty implementacji żadnej specjalnej klasy ani interfejsu. Specyfikacje trwałości obiektów są zazwyczaj zdefiniowane w metapliku XML. Obsługiwane języki zapytań są z natury zorientowane obiektowo. Pomimo wielu dobrych funkcji, specyfikacja JDO nie zyskała dużej akceptacji wśród społeczności programistów.
Java Persistence API
Istniało wiele zastrzeżonych struktur trwałości, zarówno w domenie komercyjnej, jak i w domenie open source. Frameworki takie jak Hibernate i TopLink wydawały się całkiem ładnie zaspokajać potrzeby aplikacji. W rezultacie Hibernate został wybrany jako podstawowa podstawa do stworzenia standardowego modelu trwałości zwanego JPA.
JPA to standardowa, lekka struktura trwałości Java, która pomaga tworzyć mapowanie relacyjne obiektów za pomocą POJO. JPA pomaga również zintegrować trwałość w skalowalnej aplikacji korporacyjnej. Jest łatwy w użyciu, ponieważ istnieje tylko niewielka liczba klas, które muszą zostać udostępnione aplikacji zainteresowanej wykorzystaniem modelu trwałości JPA. Użycie POJO jest prawdopodobnie najbardziej intrygującym aspektem JPA. Oznacza to, że w obiekcie nie ma nic szczególnego; to sprawia, że jest trwały. Mapowanie obiektowo-relacyjne jest oparte na metadanych. Można to zrobić za pomocą adnotacji wewnętrznie w kodzie lub zewnętrznie. za pomocą XML.
Trwałe interfejsy API JPA istnieją jako oddzielna warstwa od trwałego obiektu. Logika biznesowa zazwyczaj wywołuje interfejs API i przekazuje trwały obiekt do działania na nim. Chociaż aplikacja jest świadoma trwałego interfejsu API, trwały obiekt, będący POJO, jest całkowicie nieświadomy jego zdolności do trwałości.
Wniosek
Ten artykuł zawiera przegląd niektórych zastrzeżonych rozwiązań dostępnych przed wprowadzeniem JPA, takich jak mapowanie danych, JDBC i EJB. Chodzi o to, aby dać wgląd w to, co doprowadziło do powstania JPA, a także trochę o trwałej technice jego poprzednika. Czekać na dalsze informacje; kolejne artykuły zagłębiają się w bardziej szczegółowe aspekty JPA API.
