OR-Mapping (Hibernate) versus JDBC

[noisebreath]

Hi,

mich würd mal interessieren was eure meinung zu OR-Mappern ist. Habt ihr gute Erfahrung damit gemacht? Was sind eurer Meinung nach die Vor- und Nachteile? Wo würdet ihr OR-Mapper wie Hibernate eher einsetzen und wo würdet ihr das eher lassen?
Eigentlich interessiert mich dazu alles mögliche weil ich am überlegen bin ob es sich für mich lohnt mich damit auseinander zu setzen. Mir fehlen aber informationen um eine entscheidung zu treffen.

Vorteilhaft scheint mir zu sein, dass ich einfache übertragung von meinen Objekten auf tabellen hab (attribute -> spalten etc). Mehr oder weniger zugriff auf die DB hab , was ich doch aber auch mit einem plugin ala SQL-query hätte.
Wie gesagt ich sehe nicht sooo sehr den Sinn dahinter, daher lasst die Diskussionspiele beginnen

lg noise

 

[Guest]

Mit JPA (Hibernate ist nur eine von vielen Implementierungen, aber eine, die bereits sehr weit ist) entwickelt
man einfach objektorientiert und Persistence ist ein netter "Nebeneffekt".

Man arbeitet damit auf einem etwas höheren Abstraktionsniveau als mit reinem SQL und erfindet das Rad nicht
immer wieder neu. Wenn du wirklich sehr datenintensive Anwendung vor hast (damit meine ich wirklich massenweise
Daten hin und her schaufeln, nicht die üblichen betriebswirtschaftlichen Anwendungen), dann ist es vielleicht nicht
der beste Weg. Dazu sind TransactSQL, PL/SQL etc. besser geeignet. Da im RDBMS Bereich ist die Zeit nicht still
geblieben.

Ob es sich lohnt damit zu arbeiten? Ein klares ja.

 

[maki]

>> Eigentlich interessiert mich dazu alles mögliche weil ich am überlegen bin ob es sich für mich lohnt mich damit auseinander zu setzen.

Es lohnt sich, wenn du JDBC schon kannst, wäre dass der nächste Schritt.

 

[noisebreat]

Persistenz ist ein Begriff aus der Informatik, der die Fähigkeit bezeichnet, Daten (oder Objekte) in nicht-flüchtigen Speichermedien wie Dateisystemen oder Datenbanken zu speichern.

Ich versteh ncith so genau warum das persistenter als ne normale nicht OR-DB ist. Objektorientiert ist klar hab ich ja auch so schon erkannnt aber das mit der persistenz hab ich jetzt schon paar mal mitbekommen, daher würd ich um etwas aufklärung bitten


lg
noise

 

[SlaterB]

JDBC kann man genauso als Persistenz eines Java-Programms bezeichnen,
so wie Konsole, AWT und HTML alles Views/ Ausgaben wären

innerhalb der Persistenz gibts verschiedene Ansätze, Hibernate ist ein Framework in diesem Bereich, damit ein Persistenz-Framework,
dass bedeutet nicht, dass JDBC was anderes ist,

OR-Mapper ist dagegen gewiss ein Begriff, der nur einem der beiden gerecht wird


--------

Sinn von Persistenz-Schichten ist immer, von der Objekt-Welt in die Speicherung zu vermitteln, sei dies eine DB oder eine schlichte Textdatei,

Hibernate ist JDBC in zwei Dingen überlegen,
1. schlicht in der Menge der Funktionalität und vorgegebenen Klassen wie Session, Transaction, wie eines Caches + automatischen Abgleich geladener Daten usw.

2.
mit JDBC bist du in gewisser Hinsicht auf einzelne Arbeitsschritte angewiesen,
du kannst eine Methode
savePerson(Person x)
schreiben, mit Inhalt
createStatement(save sql kommando)

wenn du nun eine Person laden willst oder sonstige Queries brauchst, musst du wieder bei 0 anfangen,
kannst dir komplett neue SQL-Kommandos schreiben, ob sie was mit dem restlichen Programm zu tun haben oder nicht,

bei Hibernate wird die Klasse Person per Konfiguration einmalig mit einer bestimmten DB-Tabelle verknüpft,
wenn die DBTabelle Person_Table_XY3020 heißt, dann taucht dieser Name "Person_Table_XY3020" genau einmal im Programm auf und sonst nie wieder,
in der Konfiguration werden zudem Fremdschlüsselbeziehungen der Datenbank passend zu Objektbeziehungen beschrieben,

dies hat den Vorteil, dass Datenbankanfragen in einer ganz anderen Dimension beschrieben werden können, in einer eigenen neuen SQL-ähnlichen Sprache,
der Query "select p from Person p where p.nachbar = p2" (das ist keine Vereinfachung, genau so kann die Query lauten) kann eine komplette Person als Parameter für p2 übergeben werden
und das Ergebnis ist bereits ein fertiges Person-Objekt, statt mühsam aus allen Elementen eines ResultSets einen Person-Konstruktor selber zu befüllen,

manche einfache Queries wie laden/ speichern entfallen völlig und können durch Java-Kommandos wie
session.save(person);
ersetzt werden

 

[noisebreath]

sweet.danke slater. mit dem was ich drüber gelesen hab und dem was du hier geschriebeb hast hab ich nun vollkommen verstanden was sache ist
scheint ja wirklich eine tolle sache zu sein!
danke nochmals!