NHibernate oder eigener Mapper?

Hallo zusammen,

ich überlege gerade ob ich NHibernate als O/R-Mapper einsetze.

Grundsätzlich habe ich keine Ahnung wie das Framework wirklich funktioniert. Was ich rausbekommen habe ist, dass der Mapper die Objekte in XML-Struktur beschreibt und dann die Attribute (also den Zustand) in Tabellen mapped. Also die Schnittstelle emuliert, die MSSQL im Gegensatz zu Oracle (als objekt-relationale DB) eben nicht hat.

Ich frage mich grade wo der Vorteil des Mappers ist. Ich könnte doch auch genausoschnell selber so einen Mapper erstellen, oder? Wenn ich die Struktur der Objekte eh nicht ablege, kann ich doch jedem meiner Objekte eine UID verpassen und so sogar Aggregationen als 1:n Relationen in mehreren Tabellen abbilden.

Hat jemand Erfahrungen damit? Meinungen?

Dumme Jung braucht Entscheidungshilfe 😁

Danke und schönen Abend noch.

🙂 Torsten

Wie meinst du das "die Struktur der Objekte nicht ablegen"? Ein O/R-Mapper macht genau das, er bildet einzelne Klassen auf eine oder mehrere Datenbanktabellen ab. Desweiteren mappt er die Beziehungen zwischen den Klassen: Vererbungsbeziehungen, Assoziationen, 1:n/m:n-Beziehungen (Collections) und noch ein paar andere.

Um die Änderungen eines kompletten Objektgraphen mit (N)Hibernate zu speichern, reicht:

ISerializable id = session.Save(objectGraph);

Um Objektgraph wieder zu laden reicht:

ObjectGraph objectGraph = (ObjectGraph)session.Load(typeof(ObjectGraph), id);

Hinzu kommt die einfache, aber mächtige Anfragesprache HQL. Z.B. kann man sowas schreiben:

// Mapping
// class: Parent, subclasses: Mother, Father
// class: Child

// Alle Mütter, die ein Kind älter als 15 haben.
IList mothers = session.Find(
   "select m from Mother m
   join m.children c
   where c.age > 15");

// Die selbe Anfrage aus entgegengesetzter Richtung.
IList mothers = session.Find(
   "select c.mother from Child c
   where c.age > 15");

HQL-Anfragen werden im Hintergrund in den eingestellten SQL-Dialekt übersetzt. Zumindest Hibernate kommt mit sehr vielen Datenbanksystemen zurecht (bei NHibernate weiss ich es nicht). Man braucht sich also nicht einmal mehr um die verschiedenen SQL-Dialekte zu kümmern.

Ans selber Schreiben solltest du gar nicht erst denken, kann nur schiefgehen. Die Frage ist, ob ein Mapper eingesetzt werden soll oder nicht.

Vorteile:

• weniger Code,
• einfacher, übersichtlicher und konsistent.
• leicht wartbar.
• läuft (wenn getestet) ohne Anpassung auf verschiedenen Datenbanken.

Nachteile:

• langsamer als natives SQL.
• Zwischenschicht, die die Fehlersuche erschwert (sehr viel Magie).
• Mapping-Definition bei vorgegebenem DB-Schema kann sich schwierig gestalten.
• In NHibernate: keine Bulk-Updates. Die kann man aber über die Verbindung von Hibernate direkt an die Datenbank absetzen, wirkt sich nur nicht auf die bereits geladenen Objekte aus.

Hallo Pulpapex,

danke für Deine Antwort. Mit "Struktur" meinte ich die Methoden des Objekts. Es werden nur die Zustände, also Attribute, Werte, Zusicherungen gespeichert, richtig?

Was ich so gelesen habe, muss man für jedes Objekt eine XML-Struktur anlegen, die besagt, dass mein Objekt diese und welche Attribute mit diesen und welchen Wertetypen und Zusicherungen hat. Dann werden die gegen eine rel. Tabelle gemapped.
Und auch in HQL muss man die Beziehungen / Collections kennen mit denen Objekte verknüpft sind.

Naja, und da dachte ich, dass kann ich auch selber bauen ... wahrscheinlich ist es aber dumm das Rad neu zu erfinden.

Kennst Du vielleicht ein gutes Tutorial für mich?

Danke vielmals,
🙂 Torsten

Ich möchte wetten, dass in Hibernate mehrere Mannjahre Entwicklungsarbeit stecken. Viel Spass beim Selbermachen....

Kosten Hibernate: 0 €
Kosten Eigenentwicklung: >500.000€

Wie verklickerst du das deinem Chef?

Danke. Polemik bringt mich aber auch nicht weiter.

Das war keine Polemik, sondern nur das Problem auf den Punkt gebracht. Nartürlich kannst du Hibernate nachcoden, vielleicht sogar besser.

Aber Hibernate ist erstmal nur ein Infrastruktur-Tool. Unter kommerziellen Gesichtspunkten muss die Eigenentwicklung sich also lohnen. Entweder du kannst das Ding dann als Produkt verkaufen oder es muss sich innerhalb des Projektes, z.B. durch höhere Produktivität (im Vergleich zu Hibernate) amortisieren.

Die von mir geschätzten Zahlen waren eher zu niedrig gegriffen (2-3 Mannjahre bei durchschnittlichem Entwicklergehalt inkl. Lohnnebenkosten).

Du hast gefragt, wie wir den Sinn eine solchen Eigenentwicklung einschätzen. Unter kommerziellen Gesichtspunkten macht es vermutlich keinen Sinn.

Polemisch war allenfalls die Angabe von Null-Kosten bei Hibernate. Das stimmt so nicht, weil man die Schulungskosten für die Entwickler, die damit arbeiten einrechnen muss. Hätten die Entwickler den O/R-Mapper selbst geschrieben, fallen diese Kosten nicht an.

Also gebe jedem Entwickler drei Wochen Zeit sich einzuarbeiten. Summa summarum kommst du dann auf ein paar 10.000€ Kosten für Hibernate.

Hallo Svenson,

danke, ich konnte mir auch nicht vorstellen, dass Du hier rumpolemisierst. 👍

In Bezug auf Stabilität und Kosten macht der Einsatz von Hibernate natürlich Sinn, ich glaube auch, ich bin falsch verstanden worden. Ich wollte Hibernate nicht neu bauen, sondern frage mich auf rein technischer Ebene, ob mir das Ding wirklich soviel Arbeit abnimmt, dass sich ein Einarbeiten lohnt.

Aber da mich das interessiert versuche ich es nochmal: 😁
Wir haben drei Dinge beim Mapping. Die Objekte, den Mapper und die DB.

Objekte und DB haben wir, also brauchen wir noch den Mapper, der aus unseren Objekten Tupel baut. Das macht er, indem er die Attribute der Objekte "kennt" und die Werte dieser typisiert in ein Relationenattribut umsetzt. (Und umgekehrt)

So, damit der Mapper das sauber macht, braucht er eine Beschreibung der Objekte, die als XML-Struktur vorliegt. (Attributtyp und Zusicherungen) Diese XML-Struktur muss ich aber für jedes neue Objekt anlegen, richtig? (Und hier kann der Denkfehler sein!)

Wenn ich jetzt selber hingehe und mein Objekte (dessen Struktur ich ja kenne) auslese und in eine entsprechende Tabelle mappe (also Feld1 -> Attr1, Feld2 -> Attr2), dann mache ich ja nichts anderes als Hibernate, oder? Und ob ich jetzt die Struktur des Objekts in XML beschreibe, oder eben das Query baue hält sich doch vom Aufwand gleich?

Das gilt natürlich nur für ein kleines, übersichtliches Projekt mit bspw. < 20 Objekten.

So, ist das jetzt total falsch gedacht? 🤔

Danke,
🙂 Torsten

Wenn Du mal eine ganz kleine Einführung in das haben willst, was demnächst für
das FW 2.0 herauskommt, solltest Du Dir unbedingt mal "Objectspace" oder wie
es jetzt heissen wird Linq, DLinq oder XLinq anschauen.

http://msdn.microsoft.com/netframework/future/linq/

Und wenn Du mal einen wirklich einfachen Einblick in die Thematik haben willst
schau Dir mal einen einfachen Mapper an:
http://www.codeproject.com/cs/database/SqlWrapper.asp

Die kommen beide ohne eine externe Datei aus, da sie mit Attributen arbeiten.