22. Fazit
Lassen Sie uns noch einmal zusammenfassen, was wir in diesem Dokument behandelt haben. Wir haben zwei [DAO]-Schichten unter Verwendung einer der folgenden beiden Architekturen untersucht:
![]() |
![]() |
Die [DAO1]-Schicht wurde mit Spring JDBC und die [DAO2]-Schicht mit Spring JPA implementiert. Die [DAO1]- und [DAO2]-Schichten implementierten dieselbe [IDAO]-Schnittstelle, was es uns ermöglichte, einen einzigen Test [JUnitTestDao] zu schreiben, um beide [DAO]-Schichten zu testen;
Nachdem dies erledigt war, haben wir die [IDAO]-Schnittstelle wie folgt im Web verfügbar gemacht:
![]() |
- In [1] wurde die [IDAO]-Schicht über eine mit Spring MVC implementierte Webschicht [2] im Web verfügbar gemacht. Tatsächlich ist es die [IDAO]-Schnittstelle, die verfügbar gemacht wird, und wir haben zwei Versionen des Webdienstes erstellt, je nachdem, ob diese Schnittstelle mit einer [DAO-JDBC]- oder einer [DAO-JPA-JDBC]-Architektur implementiert ist;
- In [B] nutzt ein Remote-Client die vom Webservice bereitgestellten URLs, die Zugriff auf die Methoden der [IDAO-Server]-Schicht gewähren. Wir haben sichergestellt, dass die [DAO-Client]-Schicht [3] die [IDAO-Server]-Schnittstelle [1] implementiert. Dadurch konnten wir denselben [JUnitTestDao]-Test wiederverwenden, der bereits zweimal zum Einsatz gekommen war;
- In [3] wurde die [DAO-Client]-Schicht unter Verwendung von Spring RestTemplate implementiert;
Anschließend haben wir den Zugriff auf den Webdienst gesichert:
![]() |
- In [5] durchläuft die HTTP-Anfrage des Clients eine mit Spring Security implementierte Authentifizierungsschicht;
Daraufhin haben wir die bisherige Architektur wie folgt weiterentwickelt:
![]() |
- In [3] ist die Client-Anwendung selbst eine Webanwendung, die vom Webserver [4] bereitgestellt wird. Die Client-Anwendung zeigt im Browser ein Formular [5] an, über das die URLs des sicheren Webdienstes abgefragt werden können. Der HTTP-Zugriff auf den sicheren Webdienst wird von einer in JavaScript implementierten [jS]-Schicht abgewickelt. Diese Architektur nutzt sogenannte domänenübergreifende Anfragen:
- Der Webdienst stellt URLs der Form [http://machine1:port1/] bereit;
- die Client-Webanwendung wird von einer URL [http://machine2:port2/] heruntergeladen. Wenn [http://machine2:port2/] nicht mit [http://machine1:port1/] identisch ist (gleicher Rechner, gleicher Port), blockiert der Client-Browser HTTP-Aufrufe aus der [DAO-client-js]-Schicht. Um dieses Problem zu beheben, muss der Webdienst domänenübergreifende Anfragen zulassen;
Die vorgestellten Projekte wurden mit den folgenden sechs Datenbanken getestet:
- MySQL 5 Community Edition;
- SQL Server 2014 Express;
- PostgreSQL 9.4;
- Oracle Express 11g Release 2;
- IBM DB2 Express-C 10.5;
- Firebird 2.5.4;
Für jedes dieser DBMS haben wir vier verschiedene [DAO]-Schichten entwickelt:
- eine mit Spring JDBC implementierte Schicht;
- eine mit Spring JPA und dem Hibernate-JPA-Provider implementierte Schicht;
- eine mit Spring JPA und dem EclipseLink-JPA-Provider implementierte Schicht;
- eine mit Spring JPA und dem OpenJPA-JPA-Provider implementierte Schicht;
Somit wurde eine Reihe von vierundzwanzig verschiedenen Konfigurationen vorgestellt. Es wurden große Anstrengungen im Hinblick auf die Code-Refaktorisierung unternommen:
- Der Großteil des Codes wird nur einmal geschrieben. Er basiert auf zwei Maven-Konfigurationsprojekten:
- Das eine konfiguriert die JDBC-Schicht;
- das andere konfiguriert die JPA-Schicht;
![]() |
![]() |
Das Maven-Konfigurationsprojekt für die JDBC-Schicht [1] eines bestimmten DBMS ermöglicht:
- das Importieren des JDBC-Treiberarchivs;
- die Zugangsdaten für die verwendete Datenbank sowie die verschiedenen SQL-Anweisungen zu definieren, die die [DAO1]-Schicht an den JDBC-Treiber sendet. Obwohl SQL standardisiert ist, stießen wir auf Portabilitätsprobleme, die hauptsächlich darauf zurückzuführen waren, dass Abfragen Tabellen- und Spaltennamen enthielten, die sich in bestimmten DBMS als verbotene Schlüsselwörter herausstellten (die Tabelle ROLES bei DB2, die Spalte PASSWORD bei Firebird). Darüber hinaus ist die Groß-/Kleinschreibung bei Spaltennamen normalerweise irrelevant, doch bei PostgreSQL stießen wir auf ein Problem bezüglich der ID-Spalte des Primärschlüssels in den Tabellen. Diese musste in Kleinbuchstaben als „id“ benannt werden;
Die drei Maven-Projekte zur Konfiguration der JPA-Schicht [2] eines bestimmten DBMS ermöglichen:
- das Importieren des JPA-Implementierungsarchivs;
- die Konfiguration der JPA-Implementierung, die für das jeweilige verbundene DBMS verwendet wird. Tatsächlich ist es die JPA-Schicht, die SQL-Befehle an die JDBC-Schicht sendet. Um effektiv zu sein, muss sie das DBMS kennen, damit sie ihm SQL-Befehle senden kann, die es erkennt. Diese Befehle können sowohl das proprietäre SQL dieses DBMS als auch dessen spezifische Funktionen (Datentypen, Sequenzen, Trigger, Prozeduren, automatische Generierung von Primärschlüsseln usw.) nutzen;
Wir haben daher vierundzwanzig Maven-Konfigurationsprojekte (4 Konfigurationen × 6 DBMS) erstellt, auf denen alle anderen Datenbankoperationsprojekte basierten. Da in den obigen Diagrammen die Schichten [DAO1] und [DAO2] dieselbe Schnittstelle bereitstellen, wurden die 24 Konfigurationen der beiden oben genannten Architekturen mit einer einzigen Testklasse [JUnitTestDao] getestet. Nachdem diese Architekturen verifiziert waren, gab es keine weiteren Schwierigkeiten:
- Das Maven-Projekt zur Veröffentlichung der Datenbank im Web basiert auf diesen beiden Architekturen. Daher gibt es auch hier 24 mögliche Konfigurationen;
- das Maven-Projekt zur Sicherung des Zugriffs auf den Webdienst baut auf dem vorherigen Projekt auf und verfügt ebenfalls über 24 mögliche Konfigurationen;
- schließlich baut das Maven-Projekt, das domänenübergreifende Anfragen an den sicheren Webdienst ermöglicht, auf dem vorherigen Projekt auf und verfügt ebenfalls über 24 mögliche Konfigurationen;
Obwohl dieses Dokument nicht alle Möglichkeiten der Java-Sprache oder alle ihre Anwendungsbereiche abdeckt, kann es als Lernressource für die Sprache genutzt werden. Leser, die den Inhalt dieses Kurses beherrschen, haben sowohl in der Anwendung der Sprache als auch im Spring-Framework ein „fortgeschrittenes Java“-Niveau erreicht. Sie können ihre Java-Ausbildung dann mit den folgenden Büchern fortsetzen:
- [Spring MVC and Thymeleaf by Example] [http://tahe.developpez.com/java/springmvc-thymeleaf], das die Erkundung des Spring-Ökosystems fortsetzt, indem es dessen Zweig „MVC-Webprogrammierung“ vorstellt. Es verwendet eine komplexere Datenbank als die hier behandelte;
- [AngularJS / Spring MVC Tutorial] [http://tahe.developpez.com/angularjs-spring4], das eine Client/Server-Webarchitektur vorstellt, bei der der Client mit dem [AngularJS]-Framework und der Server mit [Spring MVC] implementiert wird;
- [Einführung in Java EE] [http://tahe.developpez.com/java/javaee], das sich vom Spring-Ökosystem wegbewegt und sich einer Webarchitektur zuwendet, die auf JSF (Java Server Faces) und EJB (Enterprise JavaBeans) basiert;
- [Einführung in die Android-Tablet-Programmierung] [http://tahe.developpez.com/android/exemples-intellij-aa], das eine Client/Server-Architektur beschreibt, bei der der Client ein in Java programmiertes Android-Tablet und der Server ein mit Spring MVC implementierter Webdienst ist;






