Bestmögliche Entkopplung der Datenbankanbindung

Hallo,
ich beginne gerade mit einem Projekt, bei dem Text- und Datenverarbeitung im Mittelpunkt steht. Es wird an zahlreichen Stellen in verschiedenen Modulen auf (eventuell mehrere verschiedene) Datenbanken zugegriffen.
Deshalb möchte ich die Datenbankanbindung so gut es geht vom restlichen Code entkoppeln. Mir schwebt eine Modularisierung mit Hilfe von Gradle vor, so dass die Datenbankanbindung eine eigene Library darstellt.Diese kann dann in allen Teilprojekten verwendet werden, nutzt ihrerseits aber wieder Librarys für die Datenbankanbindung.
Ich hinke leider der Java-Entwicklung immer ein wenig hinterher, da ich es nicht beruflich mache. Deshalb würde ich gerne von Euch wissen.
1) Klingt das nach einem durchdachten Ansatz? Oder was sollte ich anders handhaben?
2) Klingt das auch dann noch nach einem durchdachten Ansatz, wenn man sowohl relationale als auch NoSQL-Datenbanken einsetzen möchte? Müssen hier noch Zwischenschichten eingezogen werden, damit es funktioniert oder sollten zwei eigenständige Datenbanklibs erstellt werden?
3) Welche vorhandenen Libs oder Frameworks sollte ich mir für den (relationalen) Datenbankzugriff Stand 2015 angucken? Wohlgemerkt geht es mir um das Ablegen und Lesen von textuellen Daten und nicht um das Persistenzhalten von Objekten. Ich benötige jedoch die Freiheit, auch komplexe Abfragen stellen zu können.

Vielen Dank für Eure Hilfe
 

JuKu

Top Contributor
Hat der User später Zugangsdaten zur Datenbank?
Ansonsten klingt es gut.

NoSQL Datenbanken funktionieren komplett anders als MySQL Datenbanken, die Speicherung erfolgt auch anders, meistens hat man keine Tabellen, sondern z.B. Key-Value-Stores.

JDBC ist die Java library bzw. Treiber für relationale Datenbanken.
 

Tobse

Top Contributor
Deinen DBAL (=Database Abstraction Layer) in eine eigene Library zu packen ist der erste Schritt. Es geht vor allem darum, wie @JuKu schon andeutete, dass nachher in deinem Code keine SQL oder Graph Statements stehen; denn die binden dich an die DB wie eine Fußfessel.

Ich würde dir zu einem guten ORM raten, z.B. Hibernate. Der übernimmt wirklich alles; wenn du den konsequent einsetzt kannst du deine Logik komplett von der DB abkoppeln.
 

abollm

Top Contributor
Deinen DBAL (=Database Abstraction Layer) in eine eigene Library zu packen ist der erste Schritt. Es geht vor allem darum, wie @JuKu schon andeutete, dass nachher in deinem Code keine SQL oder Graph Statements stehen; denn die binden dich an die DB wie eine Fußfessel.

Ich würde dir zu einem guten ORM raten, z.B. Hibernate. Der übernimmt wirklich alles; wenn du den konsequent einsetzt kannst du deine Logik komplett von der DB abkoppeln.

Die Logik komplett von der DB abkoppeln zu wollen, ist eine Chimäre. Das geht in letzter Konsequenz nicht. Du musst letztlich früher oder später -- ich rede hier von großen Projekten -- immer Kompromisse eingehen, weil sich die verschiedenen RDBMS oder auch ORDBMS wie IBM DB2, Oracle und MS SQL Server bei z. B. ihrem Transaktionsmanagement, ihren Locking-Mechanismen etc. unterscheiden.
 

Tobse

Top Contributor
Die Logik komplett von der DB abkoppeln zu wollen, ist eine Chimäre. Das geht in letzter Konsequenz nicht. Du musst letztlich früher oder später -- ich rede hier von großen Projekten -- immer Kompromisse eingehen, weil sich die verschiedenen RDBMS oder auch ORDBMS wie IBM DB2, Oracle und MS SQL Server bei z. B. ihrem Transaktionsmanagement, ihren Locking-Mechanismen etc. unterscheiden.
Da stimme ich dir zu. Mein Aussage war auch eher so gemeint, dass die Business-Logik mit entsprechenden Mocks des DBAL komplett im RAM laufen kann (=Testbarkeit) und dass die Business-Logik sich nicht an irgendwelche Reihenfolgen halten muss, damit Foreign-Key-Constraints funktionieren (=ORM).
Schlussendlich ist es ja auch so: wenn man die Logik so weit von der DB getrennt hat, dass obiges gegeben ist, ist eine Migration auf eine andere DB um ein Vielfaches Einfacher. Ich kenne auch Projekte, die auf Oracle, DB2 und MSSQL laufen - ohne, dass die Business-Logik dafür Vorkehrungen trifft (dadurch bedingt, dass die Logik vor dem Projekt da war)
 

abollm

Top Contributor
Da stimme ich dir zu. Mein Aussage war auch eher so gemeint, dass die Business-Logik mit entsprechenden Mocks des DBAL komplett im RAM laufen kann (=Testbarkeit) und dass die Business-Logik sich nicht an irgendwelche Reihenfolgen halten muss, damit Foreign-Key-Constraints funktionieren (=ORM).
Schlussendlich ist es ja auch so: wenn man die Logik so weit von der DB getrennt hat, dass obiges gegeben ist, ist eine Migration auf eine andere DB um ein Vielfaches Einfacher. Ich kenne auch Projekte, die auf Oracle, DB2 und MSSQL laufen - ohne, dass die Business-Logik dafür Vorkehrungen trifft (dadurch bedingt, dass die Logik vor dem Projekt da war)

Das unterscheidet sich in der Praxis leider immer weniger oder eher mehr von dem von dir erwähnten Ansatz.

Ich bin aktuell in einem sehr großen IT-Projekt tätig, in dem eine JEE-Anwendung eines bekannten Software-Herstellers auf eine höhere Version portiert wird. Warum das geschieht, würde an dieser Stelle zu weit führen (das hier zu posten wäre irgendwo auch eine Art Lachnummer). Der Knackpunkt ist aber, dass man durch das notwendige Portieren die Gelegenheit ergriffen hat und auch gleich auf das RDBMS des erwähnten Herstellers migriert. Du glaubst nicht, welcher Aufwand allein durch das Migrieren auf das andere RDBMS entsteht. Und das, obwohl der Software-Hersteller die drei großen professionellen (O)RDBMS unterstützt, also von jeher die Datenbankunabhängigkeit seines Produkts propagiert hat.
 

Tobse

Top Contributor
Du glaubst nicht, welcher Aufwand allein durch das Migrieren auf das andere RDBMS entsteht. Und das, obwohl der Software-Hersteller die drei großen professionellen (O)RDBMS unterstützt, also von jeher die Datenbankunabhängigkeit seines Produkts propagiert hat.
Ich mache mir keine Vorstellung, dazu habe ich noch zu wenig Einblicke in Projekte dieser Größenordnung gehabt.
 
Ähnliche Java Themen
  Titel Forum Antworten Datum
pkm Frage zu Encodingproblem bei einer Datenbankanbindung Datenbankprogrammierung 1
L Speicherverbrauch Java Anwendung mit einer Datenbankanbindung Datenbankprogrammierung 19
J Derby/JavaDB Datenbankanbindung Eclipse und Derby Datenbankprogrammierung 7
M Java Datenbankanbindung funktioniert nicht Datenbankprogrammierung 4
T MySQL Problem mit Datenbankanbindung Datenbankprogrammierung 4
Z PostgreSQL Java Servlets mit Datenbankanbindung Datenbankprogrammierung 3
B Datenbankanbindung JSP Datenbankprogrammierung 7
B MySQL Problem mit Datenbankanbindung an MySQL Datenbankprogrammierung 2
R MySQL Voraussetzungen für eine erfolgreiche Datenbankanbindung mittels JDBC Datenbankprogrammierung 2
C Datenbankanbindung mit einem JButton Datenbankprogrammierung 12
M Servlet in JSP anbinden // Datenbankanbindung in JSP Datenbankprogrammierung 8
S MySQL Datenbankanbindung extra Klasse Datenbankprogrammierung 10
C Pokergame + Datenbankanbindung (Wahrscheinlichkeiten) Datenbankprogrammierung 16
G Probleme mit Datenbankanbindung Datenbankprogrammierung 3
A Datenbankanbindung an mySQL und Ein-/Auslesen der Daten Datenbankprogrammierung 4
A Datenbankanbindung, Grundlagen Datenbankprogrammierung 2
D Datenbankanbindung unter Linux Datenbankprogrammierung 10
D DAtenbankanbindung im OO-Aufbau Datenbankprogrammierung 5
M vorschläge bzgl. java programm mit datenbankanbindung Datenbankprogrammierung 4
M Datenbankanbindung - Passwort schützen Datenbankprogrammierung 6
M Datenbankanbindung: Java - MySQL Datenbankprogrammierung 2
K Problem mit datenbankanbindung unter access 2003 Datenbankprogrammierung 3
C Datenbankanbindung ohne ODBC JDBC Brücke Datenbankprogrammierung 5
R Fehler in Datenbankanbindung Servlet -> Access Datenbankprogrammierung 5
P Datenbankanbindung (erstmal) zu Access Datenbankprogrammierung 3
S Datenbankanbindung + HTML + Applet Datenbankprogrammierung 7
M Datenbankanbindung in Java : Newbie-Frage Datenbankprogrammierung 2
H Datenbankanbindung MySQL per JDBC Datenbankprogrammierung 4

Ähnliche Java Themen


Oben