Unternehmensanwendungen befassen sich häufig mit Vorgängen wie dem Sammeln, Verarbeiten, Umwandeln und Berichten großer Datenmengen. Diese Daten werden normalerweise auf einem Datenbankserver an einem bestimmten Ort gespeichert und bei Bedarf abgerufen. Die Anwendung ist dafür verantwortlich, die Daten aus der Datenbank zu verarbeiten und sie schließlich für den Clientverbrauch bereitzustellen. Aber die Feinheiten, die mit der Minderung des Datenaustauschs zwischen verschiedenen Architekturen verbunden sind, sind die eigentliche Herausforderung, vor der Entwickler stehen. Der Kern des Problems liegt in der Vereinfachung der komplizierten Beziehung der Datenbewegung zwischen dem Code, der zur Entwicklung der Anwendung verwendet wird, und dem Speichermodell, das für die Datenpersistenz verwendet wird. Kurz gesagt, die Idee besteht darin, einen Mechanismus für eine nahtlose Interaktion zwischen zwei unnachgiebigen Modellen zu schaffen:der objektorientierten Natur der Java-Sprache und dem relationalen Datenbankmodell.
Grundlegende APIs für Datenbanken
Die Java-Plattform verfügt bereits über Standard-APIs, um mit Datenbanksystemen in Form von JDBC-APIs zu arbeiten. Diese APIs eignen sich hervorragend für die Arbeit mit der Datenbank und stellen die Mittel bereit, die für eine bequeme Interaktion mit der Datenbank aus der Java-Sprache erforderlich sind. Das Problem ist jedoch, dass Java eine objektorientierte Sprache ist. Das JDBC stellt Kern-APIs für die Datenbankinteraktion bereit und konzentriert sich nicht darauf, die Zeilen- und Spaltenstruktur der Datenbanktabelle in eine Entitätsklasse umzuwandeln. Daher wird nach einer API-Schicht gesucht, die über der JDBC-API arbeitet. Die Persistenz-API oder JPA mindert zwei architektonisch unterschiedliche Modelle mit dem Ziel, die Fluidität des Betriebs zu nutzen. Die API hilft bei der Darstellung einer Datenbankbeziehungstabelle als POJO und kann im gesamten Java-Code auf ähnliche Weise behandelt werden. Die Kern-JDBC-API arbeitet im Hintergrund, um die Feinheiten der Kommunikation und Datenbankverbindung zu bewältigen, während JPA die Abwicklung gemäß dem objektorientierten Code der Java-Sprache ermöglicht. Die Datenzuordnung zwischen relationaler Datenbank und Java ist jedoch keine leichte Aufgabe.
Java-Persistenzunterstützung
In einer typischen relationalen Datenbank werden Informationen in einer Zeilen- und Spaltenstruktur gespeichert. Der Datenaustausch zwischen einem Datenbanksystem und dem Objektmodell der Java-Anwendung ist schwierig, da Java eine einzelne Entität als eine Klasse bezeichnet, die durch einen Satz von darauf angewendeten Eigenschaften und Operationen bezeichnet wird. Daher muss ein Java-Programmierer viele Codezeilen schreiben, um eine Verhaltensabweichung zwischen den beiden unterschiedlichen Architekturen auszugleichen. Diese Codezeilen helfen dabei, die Zeilen- und Spaltendaten der Datenbanktabelle in Java-Objekte umzuwandeln. Aber oft werden diese Codezeilen zu repetitiv, was dazu führt, dass der Quellcode mit Boilerplate-Codes vollgestopft ist. Dies ist unerwünscht und verstößt gegen das objektorientierte Grundprinzip der Wiederverwendbarkeit. Obwohl clevere Codes viele der Widrigkeiten mildern können, ist dies keine einfache Lösung. Das Aufkommen von Lösungen von Drittanbietern ist eine Atempause bei der Abbildung von Datenbankdaten auf Java-Objekte, aber sie waren nicht Standard. Jede Anbieterimplementierung unterschied sich beträchtlich von der anderen. Dies alles bedeutet, dass die Situation eine Standard-Persistenz-API-Bibliothek von der Java-Plattform selbst erforderte. Dies führte zur Einführung von Java Persistence API (JPA), insbesondere um die Lücke zwischen dem objektorientierten Domänenmodell von Java und dem Datenbanksystem zu schließen.
Eigene Lösungen
Verstehen Sie, dass es objektrelationale Lösungen schon seit geraumer Zeit gibt, sogar vor der Geburt der Java-Sprache selbst. Das TopLink-Produkt von Oracle beispielsweise startete eigentlich mit Smalltalk und wechselte später zu Java. Heute ist es Teil der OracleAS-, WebLogic- und OC4J-Server. Tatsächlich waren die beiden beliebtesten Persistenz-APIs früher TopLink von Oracle, ein proprietärer Standard im kommerziellen Bereich, und Hibernate im Bereich der Open-Source-Community. Später wurde Hibernate immer beliebter und beeinflusste stark die Erstellung der Standard-JPA-Bibliothek.
Datenmapper
Ein Data Mapper ist im Grunde ein von Martin Fowler in seinem Buch Patterns of Enterprise Application Architecture vorgeschlagenes Architekturmuster , 2003. Es bietet einen teilweisen Weg, um das objektrelationale Problem anzugehen. Der Mapper hilft beim Erstellen einer Strategie, die in die Kategorie zwischen einfachem JDBC und einer voll funktionsfähigen objektrelationalen Mapping-Lösung fällt. Hier erstellen Anwendungsentwickler einen rohen SQL-String, um Datenbanktabellen mit der Data-Mapper-Methode Java-Objekten zuzuordnen. Es gibt ein beliebtes Framework namens Apache iBatis, das diese Technik der Zuordnung zwischen SQL-Datenbank und Java-Objekt verwendet. Das Apache iBatis-Projekt wurde nun für inaktiv erklärt. Die ursprünglichen Entwickler von Apache iBatis haben das Projekt jedoch auf MyBatis übertragen und es wird aktiv weiterentwickelt.
Im Gegensatz zu anderen objektrelationalen Problemlösungen, die das Data-Mapper-Framework wie MyBatis verwenden, haben wir die vollständige Kontrolle über SQL-Transaktionen mit der Datenbank. Es ist eine leichtgewichtige Lösung und trägt nicht den Overhead eines vollwertigen ORM-Frameworks. Aber es gibt ein Problem mit Data Mappern. Alle Änderungen am Objektmodell haben Auswirkungen auf das Datenmodell. Als Konsequenz muss man direkt erhebliche Änderungen an den SQL-Anweisungen vornehmen. Die minimalistische Natur des Frameworks hilft Entwicklern, neue Änderungen und Modifikationen je nach Bedarf zu integrieren. Data Mapper sind besonders nützlich in einer Situation, in der wir ein minimales Framework, explizite SQL-Verarbeitung und mehr Kontrolle für Entwickleränderungen benötigen.
JDBC
JDBC (Java Database Connectivity) ist eine Java-spezifische Version der ODBC-Spezifikation (Object Database Connectivity) von Microsoft. ODBC ist ein Standard zum Verbinden beliebiger relationaler Datenbanken von beliebigen Sprachen oder Plattformen. JDBC bietet eine ähnliche Abstraktion in Bezug auf die Java-Sprache. JDBC verwendet SQL, um mit der Datenbank zu interagieren. Entwickler müssen DDL- oder DML-Abfragen gemäß der syntaktischen Spezifikation der Backend-Datenbank schreiben, sie jedoch mithilfe des Java-Programmiermodells verarbeiten. Es besteht eine enge Kopplung zwischen der Java-Quelle und den SQL-Anweisungen. Wir können auf rohe SQL-Anweisungen zurückgreifen und sie je nach Bedarf statisch manipulieren. Aufgrund seiner statischen Natur ist es schwierig, Änderungen einzuarbeiten. Darüber hinaus variieren die SQL-Dialekte von einem Datenbankanbieter zum anderen. JDBC ist fest mit der Datenbank verbunden und nicht mit dem Objektmodell der Java-Sprache. Daher fühlt es sich schnell umständlich an, damit zu arbeiten, insbesondere wenn die Datenbankinteraktion aus dem Java-Quellcode zunimmt. JDBC ist jedoch die primäre Unterstützung für die Datenbankpersistenz in Java und bildet die Grundlage für High-Level-Frameworks.
EJB
Die Enterprise Java Bean (EJB) mit J2EE brachte einige Neuerungen im Bereich der Java-Persistenz in Form der Entity Bean. Die Idee war, Entwickler davon abzuhalten, direkt in die Feinheiten der Datenbankpersistenz einzugreifen. Es führte einen schnittstellenbasierten Ansatz ein. Es gibt einen spezialisierten Bean-Compiler, um die Implementierung für Persistenz, Transaktionsverwaltung und Delegierung der Geschäftslogik zu generieren. Zur Konfiguration der Entity-Beans wurden spezielle XML-Deployment-Deskriptoren verwendet. Das Problem ist, dass EJB, anstatt die Dinge zu vereinfachen, viel Komplexität eingebaut hat. Infolgedessen verlor es trotz zahlreicher nachfolgender Verbesserungen wie der Einführung der Enterprise JavaBeans Query Language (EJB QL) bald an Popularität.
Java-Datenobjekt
Das JDO (Java Data Object) versuchte, das Problem des EJB-Persistenzmodells anzugehen. Es bietet eine API für transparente Persistenz und ist für die Zusammenarbeit mit EJB und J2EE ausgelegt. JDO ist ein Produkt, das stark von objektorientierten Datenbanken beeinflusst und unterstützt wird. Persistenzobjekte sind einfache Java-Objekte, für die kein Entwickler eine spezielle Klasse oder Schnittstelle implementieren muss. Objektpersistenzspezifikationen werden normalerweise in einer XML-Metadatei definiert. Die unterstützten Abfragesprachen sind objektorientierter Natur. Trotz vieler guter Features konnte sich die JDO-Spezifikation in der Entwicklergemeinde nicht durchsetzen.
Java-Persistenz-API
Es gab eine Reihe von proprietären Persistenz-Frameworks sowohl im kommerziellen als auch im Open-Source-Bereich. Frameworks wie Hibernate und TopLink schienen die Anforderungen der Anwendung recht gut zu erfüllen. Aus diesem Grund wurde Hibernate als primäre Grundlage für die Erstellung eines standardmäßigen Persistenzmodells namens JPA ausgewählt.
JPA ist ein einfaches Standard-Java-Persistenz-Framework, das hilft, objektrelationale Zuordnungen mit POJO zu erstellen. JPA hilft auch bei der Integration von Persistenz in eine skalierbare Unternehmensanwendung. Es ist einfach zu verwenden, da es nur eine kleine Anzahl von Klassen gibt, die für eine Anwendung verfügbar gemacht werden müssen, die an der Verwendung des JPA-Persistenzmodells interessiert ist. Die Verwendung eines POJO ist vielleicht der faszinierendste Aspekt von JPA. Es bedeutet, dass das Objekt nichts Besonderes ist; das macht es haltbar. Das objektrelationale Mapping ist metadatengesteuert. Dies kann entweder durch die Verwendung von Annotationen intern innerhalb des Codes oder extern erfolgen. durch die Verwendung von XML.
Die persistenten APIs von JPA existieren als separate Schicht vom persistenten Objekt. Die Geschäftslogik ruft typischerweise die API auf und übergibt das persistente Objekt, um mit ihnen zu arbeiten. Obwohl die Anwendung die persistente API kennt, ist sich das persistente Objekt, nämlich POJO, seiner Persistenzfähigkeit überhaupt nicht bewusst.
Schlussfolgerung
Dieser Artikel gab einen Überblick über einige der proprietären Lösungen, die vor der Einführung von JPA verfügbar waren, wie z. B. Data Mapper, JDBC und EJB. Die Idee ist, einen Einblick in das zu geben, was zur Gründung von JPA geführt hat, und ein wenig über die persistente Technik seines Vorgängers. Bleiben Sie dran; Nachfolgende Artikel befassen sich mit spezifischeren Aspekten der JPA-API.
