Podnikové aplikace se často zabývají operacemi, jako je shromažďování, zpracování, transformace a vykazování velkého množství dat. Tato data jsou obvykle uložena na databázovém serveru v určitém umístění a načtena na vyžádání. Aplikace zodpovídá za zpracování dat z databáze a jejich konečnou prezentaci pro klienty. Skutečnou výzvou, které vývojáři čelí, jsou však složitosti spojené se zmírněním výměny dat mezi různými architekturami. Jádro problému spočívá v usnadnění komplikovaného vztahu pohybu dat mezi kódem použitým k vývoji aplikace a modelem úložiště používaným pro perzistenci dat. Stručně řečeno, myšlenkou je vytvořit mechanismus pro bezproblémovou interakci mezi dvěma nepoddajnými modely:objektově orientovanou povahou jazyka Java a modelem relační databáze.
Základní rozhraní API pro databáze
Platforma Java již má standardní API pro práci s databázovými systémy ve formě JDBC API. Tato rozhraní API jsou vynikající při práci s databází a poskytují prostředky nezbytné pro pohodlnou interakci s databází z jazyka Java. Problém je ale v tom, že Java je objektově orientovaný jazyk. JDBC poskytuje základní rozhraní API pro interakci s databází a nezaměřuje se na transformaci řádkové a sloupcové struktury databázové tabulky na třídu entity. Proto se hledá vrstva API, která funguje nad JDBC API. Perzistentní API, neboli JPA, zmírňuje dva architektonicky odlišné modely s cílem využít plynulost provozu. API pomáhá reprezentovat tabulku relací databáze jako POJO a lze s ním zacházet podobným způsobem prostřednictvím kódu Java. Jádro JDBC API pracuje na pozadí, aby se vypořádalo se složitostí komunikace a databázového připojení, zatímco JPA umožňuje jednání podle objektově orientovaného kódu jazyka Java. Mapování dat mezi relační databází a Javou však není snadný úkol.
Podpora vytrvalosti Java
V typické relační databázi jsou informace uloženy v řádkové a sloupcové struktuře. Výměna dat mezi databázovým systémem a objektovým modelem aplikace Java je obtížná, protože Java označuje jedinou entitu jako třídu označenou sadou vlastností a operací, které jsou na ně aplikovány. Proto, aby se přizpůsobil nesoulad chování mezi dvěma různými architekturami, musí programátor Java napsat mnoho řádků kódu. Tyto řádky kódu pomáhají transformovat data řádků a sloupců databázové tabulky na objekty Java. Tyto řádky kódu se však často příliš opakují, což vede k tomu, že zdrojový kód je plný standardních kódů. To je nežádoucí a porušuje to základní objektově orientovaný princip opětovné použitelnosti. Ačkoli chytré kódy mohou zmírnit mnoho nepříznivých okolností, není to snadné řešení. Vznik řešení třetích stran je úlevou při mapování databázových dat do objektů Java, ale nebyly standardní. Implementace každého dodavatele se od ostatních značně lišila. To vše znamená, že situace si vyžádala standardní persistentní API knihovnu ze samotné Java platformy. To vedlo k zavedení Java Persistence API (JPA), zejména k překlenutí mezery mezi objektově orientovaným doménovým modelem Java a databázovým systémem.
Proprietární řešení
Pochopte, že objektově-relační řešení existují již nějakou dobu, dokonce ještě před zrodem samotného jazyka Java. Například produkt TopLink společnosti Oracle skutečně začal se Smalltalkem a později přešel na Javu. Dnes je součástí serverů OracleAS, WebLogic a OC4J. Ve skutečnosti dvě nejoblíbenější perzistentní API bývaly Oracle TopLink, proprietární standard v komerční doméně, a Hibernate v komunitní doméně open source. Později se Hibernate stal populárnějším a silně ovlivnil vytvoření standardní knihovny JPA.
Mapovače dat
Datový mapovač je v podstatě architektonický vzor navržený Martinem Fowlerem ve své knize Patterns of Enterprise Application Architecture , 2003. Poskytuje částečný způsob, jak řešit objektově-relační problém. Mapper pomáhá vytvořit strategii, která spadá do kategorie mezi prostým JDBC a plně funkčním řešením objektového relačního mapování. Zde vývojáři aplikací vytvářejí nezpracovaný řetězec SQL pro mapování databázových tabulek na objekty Java pomocí metody mapování dat. Existuje populární framework, který používá tuto techniku mapování mezi SQL databází a Java objektem, nazvaný Apache iBatis. Projekt Apache iBatis byl nyní prohlášen za neaktivní. Původní tvůrci Apache iBatis však převedli projekt do MyBatis a je v aktivním vývoji.
Na rozdíl od jiných objektově-relačních řešení problémů pomocí rámce mapovačů dat, jako je MyBatis, můžeme mít úplnou kontrolu nad transakcemi SQL s databází. Jde o odlehčené řešení a nenese režii plnohodnotného rámce ORM. Ale je tu problém s datovými mapovači. Jakékoli změny provedené v objektovém modelu mají dopad na datový model. V důsledku toho je nutné přímo provést významné změny v příkazech SQL. Minimalistický charakter frameworku pomáhá vývojářům začleňovat nové změny a úpravy podle potřeby. Datové mapovače jsou užitečné zejména v situaci, kdy potřebujeme minimální rámec, explicitní zpracování SQL a větší kontrolu nad vývojovými úpravami.
JDBC
JDBC (Java Database Connectivity) je specifická verze specifikace ODBC (Object Database Connectivity) společnosti Microsoft. ODBC je standard pro připojení jakékoli relační databáze z jakéhokoli jazyka nebo platformy. JDBC poskytuje podobnou abstrakci s ohledem na jazyk Java. JDBC používá SQL k interakci s databází. Vývojáři musí psát dotazy DDL nebo DML podle syntaktické specifikace backendové databáze, ale zpracovávat je pomocí programovacího modelu Java. Mezi zdrojem Java a příkazy SQL existuje těsné spojení. Můžeme se uchýlit k raw SQL příkazům a manipulovat s nimi staticky podle potřeby. Vzhledem ke své statické povaze je obtížné zapracovat změny. Navíc se dialekty SQL liší od jednoho dodavatele databáze k druhému. JDBC je pevně spojeno s databází a ne s objektovým modelem jazyka Java. Práce s ním se proto brzy zdá být těžkopádná, zvláště když se zvýší interakce s databází ze zdrojového kódu Java. JDBC je však primární podporou pro persistenci databáze v Javě a tvoří základ pro rámce na vysoké úrovni.
EJB
Enterprise Java Bean (EJB) s J2EE přinesl některé nové změny v aréně persistence Javy v podobě entity bean. Záměrem bylo izolovat vývojáře od přímého zasahování do složitosti perzistence databáze. Zavedl přístup založený na rozhraní. Existuje specializovaný kompilátor bean, který generuje implementaci pro persistenci, správu transakcí a delegování obchodní logiky. Ke konfiguraci objektů beanů byly použity specializované deskriptory nasazení XML. Problém je v tom, že EJB, spíše než zjednodušovat věci, začlenil spoustu složitosti. V důsledku toho, navzdory četným následným vylepšením, jako je zavedení Enterprise JavaBeans Query Language (EJB QL), brzy ztratil na popularitě.
Datový objekt Java
JDO (Java Data Object) se pokusil vyřešit problém, kterému čelí model persistence EJB. Poskytuje rozhraní API pro transparentní persistenci a je navrženo pro práci s EJB a J2EE. JDO je produkt silně ovlivněný a podporovaný objektově orientovanými databázemi. Perzistentní objekty jsou prosté objekty Java, které nevyžadují, aby vývojář implementoval žádnou speciální třídu nebo rozhraní. Specifikace perzistence objektu jsou obvykle definovány v metasouboru XML. Podporované dotazovací jazyky jsou ve své podstatě objektově orientované. Navzdory mnoha dobrým funkcím si specifikace JDO nemohla mezi vývojářskou komunitou získat velké přijetí.
Java Persistence API
Existovala řada proprietárních rámců persistence jak v komerční doméně, tak v doméně open source. Zdálo se, že frameworky jako Hibernate a TopLink docela dobře splňují požadavky aplikace. Výsledkem bylo, že Hibernate byl vybrán jako primární základ pro vytvoření standardního modelu persistence zvaného JPA.
JPA je standardní lehký rámec pro persistenci Java, který pomáhá vytvářet objektové relační mapování pomocí POJO. JPA také pomáhá integrovat persistenci do škálovatelné podnikové aplikace. Je snadno použitelný, protože existuje jen malý počet tříd, které je třeba vystavit aplikaci, která má zájem používat model persistence JPA. Použití POJO je možná nejzajímavějším aspektem JPA. Znamená to, že na objektu není nic zvláštního; díky tomu je trvalá. Objektově-relační mapování je řízeno metadaty. To lze provést buď pomocí interní anotace v kódu nebo externě. pomocí XML.
Perzistentní API JPA existují jako samostatná vrstva od perzistentního objektu. Obchodní logika obvykle vyvolá rozhraní API a předá perzistentní objekt, aby s nimi pracoval. Přestože si aplikace je vědoma persistentního API, perzistentní objekt, který je POJO, si vůbec není vědom jeho schopnosti persistence.
Závěr
Tento článek poskytl přehled některých proprietárních řešení dostupných před zavedením JPA, jako je mapovač dat, JDBC a EJB. Cílem je poskytnout náhled na to, co vedlo k vytvoření JPA, a trochu o perzistentní technice jeho předchůdce. Zůstaňte naladěni; následující články se ponoří do specifičtějších aspektů JPA API.