Datenbankschnittstelle für Java

[Ole]

Hallo,
für meine Abschlussarbeit setze ich ein Projekt mit Java um. Die Kommunikation mit der Datenbank ist hierbei ein wichtiger Aspekt.

Wenn ich an Datenbankschnittstellen von Java denke, fällt mir die rudimentäre Schnittstelle von Java SE ein, JDBC.

Zum anderen, das Framework Hibernate. Vorteile die mir zu Hibernate spontan einfallen: Viele Abfragen werden einen abgenommen, es setzt Datenbankabfragen direkt in Java Objekte um, so dass man die Ergebnisse selbst nicht casten und Viarablen zuweisen muss und es ist sicherer, da es selbst einen Schutz gegen SQL Injection hat, wenn man prepared statements hernimmt. Zum anderen ist der Vorteil, dass sich Hibernate an JPA hält, weshalb es später leicht auswechselbar ist.

Seit ihr der Meinung, dass ich noch andere Frameworks, wie EclipseLinks, anschauen soll?

Ich suche mir aus den Büchern im Moment selbst die Informationen raus. Leider habe ich noich keins gefunden, die mehrere Frameworks gegenüber stellt und abwägt. Kennt ihr da eins? Solche Quellen-Angaben zur Festigung meiner Argumente würde sich gut machen.

Danke für eure Hilfe.

 

[Marcinek]

ORM > JDBC > Alles andere?

 

[Ole]

ORM ist am einfachsten, da dies die objektorientierte Programmierung umsetzt.
Aber dies wird von mehreren Frameworks umgesetzt, so z.B. von Hibernate.
Ich weiß zwar, dass es alternativen, wie EclipseLink gibt, aber wenn ich an ein Persistance-Framework denke, denke ich zu erst nur an Hibernate. Lohnt es sich alternativen anzusehen?

Dass darunter JDBC nicht mithalten kann, ist klar. Trotzdem will ich kurz darauf in meiner Arbeit eingehen.

Aber welche anderen Arten, die du als "Alles andere" nennst, gibt es in Java?

 

[TheDarkRose]

EclipseLink ist auch ein JPA Framework wie hibernate und wird beispielsweise im Glassfish als solches eingesetzt.

Sonst gäbe es noch objektorientierte Datenbanken wie db4o. Oder du springst auf den NoSQL Zug auf ^^

 

[Marcinek]

Also ORM und JDBC sind keine konkurierenden Frameworks.

Jedes ORM, dass ich kenne kapselt "einfach" JDBC. Da passiert das "casting" und Wertezuweisung eine Schicht tiefer.

Andere Möglichkeiten sind Sockets zur DB auf uns die Kommunikation darüber machen. Und das erledigt für dich der JDBC Treiber. you know?

Das ist keine und schongarnicht pauschale "ich bin besser" - Geschichte.



Gruß,

Martin

 

[Ole]

Danke für eure Antworten.

Das ist keine und schongarnicht pauschale "ich bin besser" - Geschichte.

ja, da hast du vollkommen recht.
War eher die Überlegung "baue ich mir die Umsetzung mit JDBC selber ein oder welche Vorteile bietet mir ein Framework".
Als Beispiel die SQL-Injection. Klar ist dies etwas, was ich slber bei JDBC umsetzen kann. Doch kann hier so schnell etwas übersehen werden, dass es sinnvoller ist, es von einem Framework übernehmen zu lassen bei dem dies von Leuten geschrieben wurden, die da mehr Ahnung haben.

Sonst gäbe es noch objektorientierte Datenbanken wie db4o. Oder du springst auf den NoSQL Zug auf ^^

Hm, gehört db4o nicht zu den NoSQL-Datenbanken?
Werde ich mir aber auf jeden Fall ansehen, danke für den Tipp

 

[homer65]

Ein Framework hatt den Nachteil, das es eine gewisse Einstiegshürde gibt. Es braucht Zeit das Framework kennen zu lernen.
Wenn man es dann aber kennen gelernt hatt, kann man die Hoffnung haben, das es einem die Arbeit erleichert.
Wenn du ein einfaches Projekt schnell fertig kriegen willst, dann verzichte möglichst auf Frameworks.
Willst du aber etwas dazu lernen und ähnliche Projekte auch in Zukunft machen, dann kann es sich lohnen ein Framework wie Hibernate zu nutzen.
Allerdings erleichert ein Framework den Entwicklern die Arbeit nicht aber den ausführenden Computern.
Wenn es darum geht Resourcen zu schonen, kann es auch Sinn machen auf Frameworks zu verzichten.

 

[JanHH]

Also die Einstiegshürde bei SQL/JDBC ist definitiv höher als die bei JPA, was ja wirklich quasi supersimpel ist ;-).

Also wenn Du eine Arbeit über die Thematik schreiben willst würd ich mich dem eher theoretisch nähern.

Wenn Du lediglich was programmieren willst würd ich JPA nehmen, ist wirklich VIEL komfortabler als nur JDBC. Ob da unter der Haube Hibernate oder EclipseLink werkelt ist erstmal egal.

Und noch ein Aspekt.. JPA ist ja auch konstruiert in Hinblick auf die Integration in andere Umgebungen, also beispielsweise in einer JEE-Umgebung, wo der JEE-Container das Transaktionsmanagement übernimmt. Auf die Spitze getrieben z.B. bei seam, wo JSF, JPA und sehr bündig in ein einziges "Metaframework" integriert sind. Da JPA als Baustein einzeln zu entfernen würde das Gesamtkonuzept über den Haufen werfen und wäre gar nicht sinnvoll.

 

[Ole]

vielen Dank für eure netten Hilfestellungen.

Sie haben mir weiter geholfen und ich denke nun in die richtige Richtung (hoff ich zumindest). Werde mich kurz mit JDBC beschäftigen aber mich dann auf JPA mit Hibernate spezialisieren.
Habe einen Benchmark verschiederen Implementierungen gesehen, bei dem db4o sehr gut abschneidet. Falls ich zum Schluss noch Zeit haben werde (oder eben nach der Abschlussarbeit für mich), werde ich mich damit beschäftigen. Will ja auch was für die Zukunft lernen.

Nochmals vielen Dank.

Wünsch euch einen guten Start ins neue Jahr.