Företagsapplikationer hanterar ofta operationer som insamling, bearbetning, omvandling och rapportering av en stor mängd data. Dessa data lagras vanligtvis i en databasserver på en viss plats och hämtas på begäran. Applikationen ansvarar för att bearbeta data från databasen och slutligen presentera dem för klientkonsumtion. Men de krångligheter som är involverade i att mildra datautbytet mellan olika arkitekturer är den verkliga utmaningen som utvecklare står inför. Kärnan i problemet ligger i att underlätta det komplicerade förhållandet mellan datarörelser mellan koden som används för att utveckla applikationen och lagringsmodellen som används för databeständighet. Kort sagt är tanken att skapa en mekanism för sömlös interaktion mellan två orubbliga modeller:Java-språkets objektorienterade karaktär och den relationella databasmodellen.
Grundläggande API:er för databaser
Java-plattformen har redan standard-API:er för att fungera med databassystem i form av JDBC API:er. Dessa API:er är utmärkta på att arbeta med databasen och tillhandahåller de medel som krävs för att interagera med databasen bekvämt från Java-språket. Men problemet är att Java är ett objektorienterat språk. JDBC tillhandahåller kärn-API:er för databasinteraktion och är inte fokuserad på att transformera rad- och kolumnstrukturen i databastabellen till en entitetsklass. Därför eftersträvas ett lager av API som fungerar ovanför JDBC API. Persistence API, eller JPA, mildrar två arkitektoniskt olika modeller med målet att utnyttja smidigheten i driften. API:n hjälper till att representera en databasrelationstabell som en POJO och kan behandlas på ett liknande sätt genom hela Java-koden. Kärnan i JDBC API arbetar i bakgrunden för att hantera invecklade kommunikationer och databasanslutningar medan JPA gör det möjligt att göra affärer enligt den objektorienterade koden för Java-språket. Datakartläggningen mellan relationsdatabas och Java är dock ingen lätt uppgift.
Stöd för Java Persistence
I en typisk relationsdatabas lagras information i en rad- och kolumnstruktur. Utbytet av data mellan ett databassystem och objektmodellen för Java-applikationen är svårt eftersom Java utser en enda enhet som en klass betecknad av en uppsättning egenskaper och operationer som tillämpas på dem. Därför, för att överensstämma med en beteendemässig oöverensstämmelse mellan de två olika arkitekturerna, måste en Java-programmerare skriva många rader kod. Dessa kodrader hjälper till att omvandla rad- och kolumndata i databastabellen till Java-objekt. Men ofta blir dessa kodrader alltför repetitiva, vilket resulterar i att källkoden är fylld med standardkoder. Detta är oönskat och strider mot den grundläggande objektorienterade principen om återanvändbarhet. Även om smarta koder kan mildra många av motgångarna, är det ingen lätt lösning. Framväxten av tredjepartslösningar är en paus i kartläggningen av databasdata till Java-objekt, men de var inte standard. Varje leverantörsimplementering varierade avsevärt från en annan. Allt detta betyder att situationen krävde ett standardbeständigt API-bibliotek från själva Java-plattformen. Detta ledde till introduktionen av Java Persistence API (JPA), särskilt för att överbrygga gapet mellan objektorienterad domänmodell av Java och databassystemet.
Egendomsskyddade lösningar
Förstå att objektrelationslösningar har funnits ganska länge, och går tillbaka till och med innan själva Java-språket föddes. Till exempel började TopLink-produkten från Oracle faktiskt med Smalltalk, och bytte sedan senare till Java. Idag är det en del av OracleAS-, WebLogic- och OC4J-servrarna. Faktum är att de två mest populära beständighets-API:erna brukade vara Oracles TopLink, en proprietär standard i den kommersiella domänen, och Hibernate i community-domänen med öppen källkod. Senare blev Hibernate mer populärt och påverkade kraftigt skapandet av JPA-standardbiblioteket.
Datamappare
En datamappare är i grunden ett arkitektoniskt mönster som föreslagits av Martin Fowler i hans bok Patterns of Enterprise Application Architecture , 2003. Det ger ett delvis sätt att ta itu med det objektrelationella problemet. Kartläggaren hjälper till att skapa en strategi som faller inom kategorin mellan vanlig JDBC och en fullfunktionell objektrelationsmappningslösning. Här skapar applikationsutvecklare en rå SQL-sträng för att mappa databastabeller till Java-objekt genom att använda datamappermetoden. Det finns ett populärt ramverk som använder denna teknik för mappning mellan SQL-databas och Java-objekt, kallad Apache iBatis. Apache iBatis-projektet har förklarats vara inaktivt nu. De ursprungliga skaparna av Apache iBatis har dock överfört projektet till MyBatis och är under aktiv utveckling.
Till skillnad från andra objektrelationella problemlösningar som använder ramverket för datakartläggning som MyBatis, kan vi ha fullständig kontroll över SQL-transaktioner med databasen. Det är en lättviktslösning och bär inte kostnaden för ett fullödigt ORM-ramverk. Men det finns ett problem med datamappare. Alla ändringar som görs i objektmodellen har återverkningar på datamodellen. Man måste göra betydande ändringar i SQL-satserna direkt som en konsekvens. Ramverkets minimalistiska karaktär hjälper utvecklare att införliva nya ändringar och modifieringar efter behov. Datakartare är särskilt användbara i en situation där vi behöver ett minimalt ramverk, explicit SQL-hantering och mer kontroll för modifiering av utvecklare.
JDBC
JDBC (Java Database Connectivity) är en Java-specifik version av Microsofts ODBC (Object Database Connectivity)-specifikation. ODBC är en standard för att ansluta vilken relationsdatabas som helst från alla språk eller plattformar. JDBC tillhandahåller liknande abstraktion med avseende på Java-språket. JDBC använder SQL för att interagera med databasen. Utvecklare måste skriva DDL- eller DML-frågor enligt den syntaktiska specifikationen för backend-databasen, men bearbeta dem med hjälp av Java-programmeringsmodellen. Det finns en tät koppling mellan Java-källan och SQL-satserna. Vi kan ta till råa SQL-satser och manipulera dem statiskt efter behov. På grund av dess statiska natur är det svårt att införliva förändringar. Dessutom varierar SQL-dialekter från en databasleverantör till en annan. JDBC är kopplat till databasen och inte till objektmodellen för Java-språket. Därför känns det snart krångligt att arbeta med, speciellt när databasinteraktion från Java-källkod ökar. JDBC är dock det primära stödet för databasbeständighet i Java och utgör grunden för ramverk på hög nivå.
EJB
Enterprise Java Bean (EJB) med J2EE medförde några nya förändringar på arenan för Java-uthållighet i form av entitetsbönan. Tanken var att isolera utvecklare från att direkt ingripa med krångligheterna med databasbeständighet. Den introducerade ett gränssnittsbaserat tillvägagångssätt. Det finns en specialiserad bönkompilator för att generera implementeringen för persistens, transaktionshantering och delegering av affärslogik. Specialiserade XML-distributionsbeskrivningar användes för att konfigurera entitetsbönor. Problemet är att EJB, snarare än att förenkla saker, inkorporerade mycket komplexitet. Som ett resultat, trots många efterföljande förbättringar, såsom introduktionen av Enterprise JavaBeans Query Language (EJB QL), förlorade det snart popularitet.
Java-dataobjekt
JDO (Java Data Object) försökte ta itu med problemet med EJB-persistensmodellen. Det tillhandahåller ett API för transparent uthållighet och är designat för att fungera med EJB och J2EE. JDO är en produkt som är starkt påverkad och stödd av objektorienterade databaser. Persistensobjekt är vanliga Java-objekt som inte kräver en utvecklare för att implementera någon speciell klass eller gränssnitt. Objektpersistensspecifikationer definieras vanligtvis i en XML-metafil. Frågespråken som stöds är objektorienterade till sin natur. Trots många bra funktioner kunde JDO-specifikationen inte få mycket acceptans bland utvecklargemenskapen.
Java Persistence API
Det fanns ett antal proprietära beständighetsramverk både inom den kommersiella domänen och domänen med öppen källkod. Ramar som Hibernate och TopLink verkade möta applikationsbehovet ganska bra. Som ett resultat valdes Hibernate som den primära grunden för att skapa en standardmodell för beständighet som kallas JPA.
JPA är en standard lättviktig Java persistensramverk som hjälper till att skapa objektrelationsmappning med POJO. JPA hjälper också till att integrera persistens i en skalbar företagsapplikation. Det är lätt att använda eftersom det bara finns ett litet antal klasser som behöver exponeras för en applikation som är intresserad av att använda JPA-persistensmodellen. Användningen av en POJO är kanske den mest spännande aspekten av JPA. Det betyder att det inte finns något speciellt med föremålet; som gör det hållbart. Den objektrelationella kartläggningen är metadatadriven. Det kan göras antingen genom att använda anteckning internt i koden eller externt. genom att använda XML.
De beständiga API:erna för JPA finns som ett separat lager från det beständiga objektet. Affärslogiken anropar vanligtvis API:et och skickar det beständiga objektet för att arbeta på dem. Även om applikationen är medveten om det beständiga API:et, är det beständiga objektet, som är POJO, helt omedvetet om sin beständighetsförmåga.
Slutsats
Den här artikeln gav en översikt över några av de patentskyddade lösningarna som var tillgängliga före införandet av JPA, såsom datamapper, JDBC och EJB. Tanken är att ge en inblick i vad som ledde till skapandet av JPA, och lite om dess föregångares ihärdiga teknik. Håll ögonen öppna; efterföljande artiklar fördjupar sig i mer specifika aspekter av JPA API.