Le applicazioni aziendali spesso si occupano di operazioni come la raccolta, l'elaborazione, la trasformazione e il reporting di una grande quantità di dati. Questi dati vengono in genere archiviati in un server di database in una posizione particolare e recuperati su richiesta. L'applicazione è responsabile dell'elaborazione dei dati dal database e, infine, di presentarli per il consumo del cliente. Ma le complessità legate alla mitigazione dello scambio di dati tra diverse architetture sono la vera sfida che gli sviluppatori devono affrontare. Il cuore del problema sta nell'alleggerire la complicata relazione di spostamento dei dati tra il codice utilizzato per sviluppare l'applicazione e il modello di archiviazione utilizzato per la persistenza dei dati. In breve, l'idea è quella di creare un meccanismo per l'interazione senza interruzioni tra due modelli inflessibili:la natura orientata agli oggetti del linguaggio Java e il modello di database relazionale.
API di base per i database
La piattaforma Java dispone già di API standard per funzionare con i sistemi di database sotto forma di API JDBC. Queste API sono eccellenti per lavorare con il database e forniscono i mezzi necessari per interagire con il database comodamente dal linguaggio Java. Ma il problema è che Java è un linguaggio orientato agli oggetti. Il JDBC fornisce API di base per l'interazione con il database e non si concentra sulla trasformazione della struttura di righe e colonne della tabella del database in una classe di entità. Pertanto, viene cercato un livello di API che funzioni al di sopra dell'API JDBC. L'API di persistenza, o JPA, attenua due modelli architettonicamente diversi con l'obiettivo di sfruttare la fluidità delle operazioni. L'API aiuta a rappresentare una tabella di relazione del database come un POJO e può essere trattata in modo simile attraverso il codice Java. L'API JDBC di base funziona in background per affrontare le complessità della comunicazione e della connessione al database, mentre JPA consente di eseguire le operazioni in base al codice orientato agli oggetti del linguaggio Java. Tuttavia, la mappatura dei dati tra database relazionale e Java non è un compito facile.
Supporto per la persistenza di Java
In un tipico database relazionale, le informazioni sono archiviate in una struttura di righe e colonne. Lo scambio di dati tra un sistema di database e il modello a oggetti dell'applicazione Java è difficile perché Java designa una singola entità come una classe denotata da un insieme di proprietà e operazioni applicate su di esse. Pertanto, per conformare una discrepanza comportamentale tra le due diverse architetture, un programmatore Java deve scrivere molte righe di codice. Queste righe di codice aiutano a trasformare i dati di riga e colonna della tabella del database in oggetti Java. Ma spesso queste righe di codice diventano troppo ripetitive, con il risultato che il codice sorgente è pieno di codici standard. Questo è indesiderabile e viola il principio di riutilizzabilità di base orientato agli oggetti. Sebbene i codici intelligenti possano mitigare molte delle avversità, non è una soluzione facile. L'emergere di soluzioni di terze parti è una tregua nella mappatura dei dati del database negli oggetti Java, ma non erano standard. Ogni implementazione del fornitore variava considerevolmente da un'altra. Tutto ciò significa che la situazione richiedeva una libreria API di persistenza standard dalla stessa piattaforma Java. Ciò ha portato all'introduzione di Java Persistence API (JPA), in particolare per colmare il divario tra il modello di dominio orientato agli oggetti di Java e il sistema di database.
Soluzioni proprietarie
Comprendi che le soluzioni relazionali a oggetti esistono da un po' di tempo, risalenti addirittura a prima della nascita del linguaggio Java stesso. Ad esempio, il prodotto TopLink di Oracle è stato effettivamente avviato con Smalltalk e successivamente è passato a Java. Oggi fa parte dei server OracleAS, WebLogic e OC4J. In effetti, le due API di persistenza più popolari erano TopLink di Oracle, uno standard proprietario nel dominio commerciale, e Hibernate nel dominio della comunità open source. Successivamente, Hibernate divenne più popolare e influenzò pesantemente la creazione della libreria JPA standard.
Mapper dati
Un data mapper è fondamentalmente un modello architettonico proposto da Martin Fowler nel suo libro Patterns of Enterprise Application Architecture , 2003. Fornisce un modo parziale per affrontare il problema relazionale degli oggetti. Il mapper aiuta a creare una strategia che rientra nella categoria tra JDBC semplice e una soluzione di mappatura relazionale a oggetti completamente funzionale. Qui, gli sviluppatori di applicazioni creano una stringa SQL grezza per mappare le tabelle di database su oggetti Java utilizzando il metodo del data mapper. Esiste un framework popolare che utilizza questa tecnica di mappatura tra database SQL e oggetti Java, chiamato Apache iBatis. Il progetto Apache iBatis è stato dichiarato inattivo ora. Tuttavia, i creatori originali di Apache iBatis hanno trasferito il progetto su MyBatis ed è in fase di sviluppo attivo.
A differenza di altre soluzioni di problemi relazionali a oggetti che utilizzano il framework dei mappatori di dati come MyBatis, possiamo avere il controllo completo sulle transazioni SQL con il database. È una soluzione leggera e non comporta il sovraccarico di un framework ORM in piena regola. Ma c'è un problema con i mappatori di dati. Eventuali modifiche apportate al modello a oggetti hanno ripercussioni sul modello dati. Di conseguenza, è necessario apportare modifiche significative alle istruzioni SQL. La natura minimalista del framework aiuta gli sviluppatori a incorporare nuove modifiche e modifiche in base alle necessità. I mappatori di dati sono particolarmente utili in una situazione in cui abbiamo bisogno di un framework minimo, di una gestione SQL esplicita e di un maggiore controllo per le modifiche degli sviluppatori.
JDBC
JDBC (Java Database Connectivity) è una versione specifica per Java della specifica ODBC (Object Database Connectivity) di Microsoft. L'ODBC è uno standard per la connessione di qualsiasi database relazionale da qualsiasi lingua o piattaforma. JDBC fornisce un'astrazione simile rispetto al linguaggio Java. JDBC utilizza SQL per interagire con il database. Gli sviluppatori devono scrivere query DDL o DML secondo le specifiche sintattiche del database back-end, ma elaborarle utilizzando il modello di programmazione Java. C'è uno stretto accoppiamento tra l'origine Java e le istruzioni SQL. Possiamo ricorrere a istruzioni SQL grezze e manipolarle staticamente in base alle necessità. A causa della sua natura statica, è difficile incorporare le modifiche. Inoltre, i dialetti SQL variano da un fornitore di database all'altro. JDBC è cablato al database e non al modello a oggetti del linguaggio Java. Pertanto, diventa presto ingombrante con cui lavorare, specialmente quando aumenta l'interazione del database dal codice sorgente Java. Tuttavia, JDBC è il supporto principale per la persistenza del database in Java e costituisce la base per framework di alto livello.
EJB
L'Enterprise Java Bean (EJB) con J2EE ha apportato alcune nuove modifiche nell'arena della persistenza Java sotto forma di bean di entità. L'idea era di isolare gli sviluppatori dall'intervenire direttamente con le complessità della persistenza del database. Ha introdotto un approccio basato sull'interfaccia. È disponibile un compilatore di bean specializzato per generare l'implementazione per la persistenza, la gestione delle transazioni e la delega della logica aziendale. Per configurare i bean di entità sono stati utilizzati descrittori di distribuzione XML specializzati. Il problema è che EJB, invece di semplificare le cose, incorporava molta complessità. Di conseguenza, nonostante numerosi miglioramenti successivi come l'introduzione di Enterprise JavaBeans Query Language (EJB QL), ha presto perso popolarità.
Oggetto dati Java
Il JDO (Java Data Object) ha cercato di affrontare il problema affrontato dal modello di persistenza EJB. Fornisce un'API per la persistenza trasparente ed è progettato per funzionare con EJB e J2EE. JDO è un prodotto fortemente influenzato e supportato da database orientati agli oggetti. Gli oggetti di persistenza sono semplici oggetti Java che non richiedono che uno sviluppatore implementi alcuna classe o interfaccia speciale. Le specifiche di persistenza degli oggetti sono in genere definite in un metafile XML. I linguaggi di query supportati sono di natura orientata agli oggetti. Nonostante molte buone caratteristiche, la specifica JDO non ha potuto ottenere molta accettazione dalla comunità degli sviluppatori.
API di persistenza Java
C'erano una serie di framework di persistenza proprietari sia nel dominio commerciale che nel dominio open source. Framework come Hibernate e TopLink sembravano soddisfare abbastanza bene le esigenze dell'applicazione. Di conseguenza, Hibernate è stata scelta come base principale per la creazione di un modello di persistenza standard chiamato JPA.
JPA è un framework di persistenza Java leggero e standard che aiuta a creare la mappatura relazionale degli oggetti utilizzando POJO. JPA aiuta anche a integrare la persistenza in un'applicazione aziendale scalabile. È facile da usare perché c'è solo un piccolo numero di classi che devono essere esposte a un'applicazione interessata all'uso del modello di persistenza JPA. L'uso di un POJO è forse l'aspetto più intrigante di JPA. Significa che non c'è niente di speciale nell'oggetto; che lo rende persistente. La mappatura relazionale degli oggetti è guidata dai metadati. Può essere eseguito utilizzando l'annotazione internamente all'interno del codice o esternamente. utilizzando XML.
Le API persistenti di JPA esistono come un livello separato dall'oggetto persistente. La logica aziendale in genere richiama l'API e passa l'oggetto persistente per operare su di essa. Sebbene l'applicazione sia a conoscenza dell'API persistente, l'oggetto persistente, essendo POJO, è completamente inconsapevole della sua capacità di persistenza.
Conclusione
Questo articolo ha fornito una panoramica di alcune delle soluzioni proprietarie disponibili prima dell'introduzione di JPA, come data mapper, JDBC ed EJB. L'idea è di dare un'idea di ciò che ha portato alla creazione di JPA e un po' della tecnica persistente del suo predecessore. Rimani sintonizzato; gli articoli successivi approfondiscono aspetti più specifici dell'API JPA.
