Virksomhedsapplikationer beskæftiger sig ofte med operationer såsom indsamling, behandling, transformation og rapportering af en stor mængde data. Disse data gemmes typisk på en databaseserver på et bestemt sted og hentes efter behov. Applikationen er ansvarlig for at behandle data fra databasen og endelig præsentere dem til klientforbrug. Men de forviklinger, der er involveret i at afbøde dataudvekslingen mellem forskellige arkitekturer, er den virkelige udfordring, som udviklere står over for. Hjertet af problemet ligger i at lette det komplicerede forhold mellem databevægelser mellem koden, der bruges til at udvikle applikationen, og lagermodellen, der bruges til datapersistens. Ideen er kort sagt at skabe en mekanisme til problemfri interaktion mellem to ubøjelige modeller:Java-sprogets objektorienterede natur og den relationelle databasemodel.
Grundlæggende API'er til databaser
Java-platformen har allerede standard API'er til at arbejde med databasesystemer i form af JDBC API'er. Disse API'er er fremragende til at arbejde med databasen og giver de nødvendige midler til at interagere med databasen bekvemt fra Java-sproget. Men problemet er, at Java er et objektorienteret sprog. JDBC'en leverer kerne-API'er til databaseinteraktion og er ikke fokuseret på at transformere række- og kolonnestrukturen i databasetabellen til en enhedsklasse. Derfor søges et lag af API, der virker over JDBC API. Persistence API, eller JPA, afbøder to arkitektonisk forskellige modeller med det mål at udnytte flydende drift. API'et hjælper med at repræsentere en databaserelationstabel som en POJO og kan behandles på samme måde gennem Java-kode. Kerne JDBC API arbejder i baggrunden for at håndtere forviklingerne ved kommunikation og databaseforbindelse, hvorimod JPA gør det muligt at foretage handlinger i henhold til den objektorienterede kode i Java-sproget. Datakortlægningen mellem relationel database og Java er dog ikke en nem opgave.
Java Persistence Support
I en typisk relationsdatabase lagres information i en række- og kolonnestruktur. Udvekslingen af data mellem et databasesystem og Java-applikationens objektmodel er vanskelig, fordi Java udpeger en enkelt enhed som en klasse, der er angivet af et sæt egenskaber og operationer, der anvendes på dem. For at tilpasse et adfærdsmæssigt uoverensstemmelse mellem de to forskellige arkitekturer skal en Java-programmør derfor skrive mange linjer kode. Disse kodelinjer hjælper med at transformere række- og kolonnedataene i databasetabellen til Java-objekter. Men ofte bliver disse kodelinjer for gentagne, hvilket resulterer i, at kildekoden er fyldt med boilerplate-koder. Dette er uønsket og overtræder det grundlæggende objektorienterede princip om genanvendelighed. Selvom smarte koder kan afbøde mange af modgangen, er det ikke en nem løsning. Fremkomsten af tredjepartsløsninger er et pusterum i at kortlægge databasedata til Java-objekter, men de var ikke standard. Hver leverandørimplementering varierede betydeligt fra den anden. Dette betyder alt sammen, at situationen krævede et standard vedholdenheds-API-bibliotek fra selve Java-platformen. Dette førte til introduktionen af Java Persistence API (JPA), især for at bygge bro mellem objektorienteret domænemodel af Java og databasesystemet.
Ejendomsbeskyttede løsninger
Forstå, at objektrelationelle løsninger har eksisteret i et stykke tid, og dateres endda tilbage før selve Java-sprogets fødsel. For eksempel startede TopLink-produktet fra Oracle faktisk med Smalltalk, og skiftede så senere til Java. I dag er det en del af OracleAS-, WebLogic- og OC4J-serverne. Faktisk plejede de to mest populære persistens-API'er at være Oracles TopLink, en proprietær standard i det kommercielle domæne, og Hibernate i open source-fællesskabsdomænet. Senere blev Hibernate mere populær og påvirkede i høj grad oprettelsen af JPA-standardbiblioteket.
Datakortlæggere
En datamapper er grundlæggende et arkitektonisk mønster foreslået af Martin Fowler i hans bog Patterns of Enterprise Application Architecture , 2003. Det giver en delvis måde at løse det objektrelationelle problem på. Kortlæggeren hjælper med at skabe en strategi, der falder ind under kategorien mellem almindelig JDBC og en fuldfunktionel objektrelationel kortlægningsløsning. Her opretter applikationsudviklere en rå SQL-streng til at kortlægge databasetabeller til Java-objekter ved at bruge datamapper-metoden. Der er en populær ramme, der bruger denne teknik til kortlægning mellem SQL-database og Java-objekt, kaldet Apache iBatis. Apache iBatis-projektet er blevet erklæret for inaktivt nu. De oprindelige skabere af Apache iBatis har dog overført projektet til MyBatis og er under aktiv udvikling.
I modsætning til andre objektrelationelle problemløsninger, der bruger datakortlægningsrammerne som MyBatis, kan vi have fuldstændig kontrol over SQL-transaktioner med databasen. Det er en letvægtsløsning og bærer ikke omkostningerne ved et fuldt udbygget ORM-rammeværk. Men der er et problem med datakortlæggere. Eventuelle ændringer i objektmodellen har konsekvenser for datamodellen. Man er nødt til at foretage væsentlige ændringer i SQL-sætningerne direkte som følge heraf. Rammens minimalistiske karakter hjælper udviklere med at indarbejde nye ændringer og modifikationer i overensstemmelse med behovet. Datakortlæggere er særligt nyttige i en situation, hvor vi har brug for en minimal ramme, eksplicit SQL-håndtering og mere kontrol til udviklerændringer.
JDBC
JDBC (Java Database Connectivity) er en Java-specifik version af Microsofts ODBC (Object Database Connectivity) specifikation. ODBC er en standard til at forbinde enhver relationel database fra ethvert sprog eller platform. JDBC giver lignende abstraktion med hensyn til Java-sproget. JDBC bruger SQL til at interagere med databasen. Udviklere skal skrive DDL- eller DML-forespørgsler i henhold til backend-databasens syntaktiske specifikation, men behandle dem ved hjælp af Java-programmeringsmodellen. Der er en tæt kobling mellem Java-kilden og SQL-sætningerne. Vi kan ty til rå SQL-sætninger og manipulere dem statisk efter behov. På grund af dens statiske karakter er det vanskeligt at inkorporere ændringer. Desuden varierer SQL-dialekter fra en databaseleverandør til en anden. JDBC er fastkablet til databasen og ikke til objektmodellen for Java-sproget. Derfor føles det hurtigt besværligt at arbejde med, især når databaseinteraktion fra Java-kildekode øges. JDBC er dog den primære understøttelse af databasepersistens i Java og danner grundlaget for rammer på højt niveau.
EJB
Enterprise Java Bean (EJB) med J2EE bragte nogle nye ændringer i arenaen for Java-vedholdenhed i form af entity bean. Ideen var at isolere udviklere fra direkte at gribe ind i forviklingerne ved databasens persistens. Det introducerede en grænsefladebaseret tilgang. Der er en specialiseret bønnekompiler til at generere implementeringen til persistens, transaktionsstyring og delegering af forretningslogik. Specialiserede XML-implementeringsdeskriptorer blev brugt til at konfigurere enhedsbeansene. Problemet er, at EJB, snarere end at forenkle tingene, inkorporerede en masse kompleksitet. Som et resultat, på trods af adskillige efterfølgende forbedringer, såsom introduktionen af Enterprise JavaBeans Query Language (EJB QL), mistede det hurtigt popularitet.
Java-dataobjekt
JDO (Java Data Object) forsøgte at løse problemet med EJB-persistensmodellen. Det giver en API til gennemsigtig persistens og er designet til at fungere med EJB og J2EE. JDO er et produkt, der er stærkt påvirket og understøttet af objektorienterede databaser. Persistensobjekter er almindelige Java-objekter, der ikke kræver, at en udvikler implementerer nogen speciel klasse eller grænseflade. Objektpersistensspecifikationer er typisk defineret i en XML-metafil. De understøttede forespørgselssprog er objektorienterede. På trods af mange gode funktioner kunne JDO-specifikationen ikke fange meget accept blandt udviklerfællesskabet.
Java Persistence API
Der var en række proprietære persistensrammer både i det kommercielle domæne og open source domæne. Rammer som Hibernate og TopLink så ud til at opfylde applikationsbehovet ganske pænt. Som et resultat blev Hibernate valgt som det primære grundlag for at skabe en standard vedholdenhedsmodel kaldet JPA.
JPA er en standard letvægts Java persistensramme, der hjælper med at skabe objektrelationel kortlægning ved hjælp af POJO. JPA hjælper også med at integrere persistens i en skalerbar virksomhedsapplikation. Det er nemt at bruge, fordi der kun er et lille antal klasser, der skal eksponeres for en applikation, der er interesseret i at bruge JPA-persistensmodellen. Brugen af en POJO er måske det mest spændende aspekt af den fælles forsamling. Det betyder, at der ikke er noget særligt ved objektet; det gør det holdbart. Den objektrelationelle kortlægning er metadatadrevet. Det kan enten gøres ved at bruge annotering internt i koden eller eksternt. ved at bruge XML.
De vedvarende API'er i JPA eksisterer som et separat lag fra det vedvarende objekt. Forretningslogikken påberåber sig typisk API'en og sender det vedvarende objekt til at operere på dem. Selvom applikationen er opmærksom på den persistente API, er det persistente objekt, som er POJO, fuldstændig uvidende om dets persistensevne.
Konklusion
Denne artikel gav et overblik over nogle af de proprietære løsninger, der var tilgængelige før introduktionen af JPA, såsom datamapper, JDBC og EJB. Ideen er at give et indblik i, hvad der førte til oprettelsen af JPA, og lidt om dens forgængers vedholdende teknik. Bliv hængende; efterfølgende artikler dykker ned i mere specifikke aspekter af JPA API.