Bestmögliche Entkopplung der Datenbankanbindung

[Alex Unkreativ]

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]

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]

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]

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]

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]

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]

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.