Hätt ich das mal eher benutzt – ORM

Eine unglückliche Basis

In Sachen ORM hat sich bei mir schon fast eine Hollywood-Reife Liebesgeschichte abgespielt. 😉 Als ich mein erstes großes Projekt begann, kannte ich ORM noch nicht. Die vorhandene Datenbank die ich anzapfen musste, war nicht sonderlich logisch aufgebaut. Teilweise waren boolsche Spalten als decimal ausgeführt, teilweise eben als bit und eben manchmal auch als varchar. Zu finden waren dann die verschiedensten Werte. Manchmal wurde sogar „true“ und „false“ in die DB geschrieben. Da eine andere Software auf dieser DB arbeitete konnte ich die Spalten aber nicht verändern. Meine Datenbankklassen mussten mit den entsprechenden „Eigenheiten“ umgehen.

Eine flüchtige Bekanntschaft

Ungefähr um 2009 herum besuchte ich einen Vortrag der „Do-Dotnet“ User Group Dortmund zum Thema ORM. Hier wurde NHibernate vorgestellt. Wie in einer Hollywood-Schnulze fand ich es schon sehr spannend, entschied ich mich aber dann dagegen. Der nachträgliche Einbau wäre nicht so einfach gewesen und einige der „Eigenheiten“ hätte ich nur schwer abbilden können. Und dann hätte ich auch noch mehr Pflegeaufwand benötigt um die XML Konfigurationsdateien zu erstellen und zu warten. Meine selbst erstellte DB Connection Klasse arbeitete ja mit der DB gut zusammen. ORM und ich verloren uns also erst einmal für Jahre wieder aus den Augen.

Das Wiedersehen

Irgendwann gab es dann ein neues Projekt. Eines bei dem es eine frische Datenbank geben würde. Da ich in der Zwischenzeit hier und da über ORM gelesen hatte und sich sowohl NHibernate als auch das Entity Framework weiterentwickelt hatten. So stand für mich fest: ORM sollte es sein. Da mir das Entity Framework zu dem Zeitpunkt nicht so zusagte, entschied ich mich für Nhibernate. Unter anderem wegen Fluent NHibernate.

Und sie lebten…

Bei dem Projekt gefielen mir vor allem zwei Vorteile besonders gut. Einfacher Datenbankwechsel und Code First Entwicklung.
Dank der Mächtigkeit von Nhibernate war es mir möglich das Programm so aufzubauen, dass es quasi ohne Konfiguration sofort mit einer internen SQLite Datenbank voll lauffähig war. Dennoch konnte man über eine einfache Konfigruationseinstellung mit vielen anderen Datenbanken verbinden.
Der zweite angenehme Punkt war, dass ich die Anwendung bauen konnte, und parallel die Datenbank mitentwickelte. In einer „Map“ Datei gab ich die Struktur vor und konnte dank Fluent Nhibernate dabei auf Code Completion zurückgreifen. Beim Ausführen der Anwendung wurde die Datenbank dann entsprechend vorbereitet. Das ermöglichte meine selbstgeschriebene DB Klasse zwar auch, aber mit Fluent konnten sich auch nicht so einfach Tippfehler einschleichen. Von Performance durch „Lazy Loading“ und den anderen Späßen schreibe ich jetzt mal nicht.

Testing mit ORM

Unit bzw. hier wohl besser Integration Tests sind immer so eine Sache. Viel lässt sich ja mit Substitutes testen, aber eben auch nicht alles. Und einen guten Teil den ich testen wollte, testete ich dann gegen eine InMemory Test-Datenbank. Das lief zuverlässig und recht fix und war somit eine große Hilfe bei der Umsetzung des Projekts.

Fazit

Die Einarbeitung in Nhibernate hat mich einiges an Zeit und auch Nerven gekostet. Auf lange Sicht habe ich aber sicherlich viel mehr Zeit und vor allem Nerven eingespart. Es gibt im Prozess einfach viele Dinge, die man einmal definiert und dann vergessen kann. So sind z.B. die allseits bekannten SQL-Injections überhaupt kein Thema. Man muss sich nicht anstrengen um sie zu vermeiden, sondern man muss sich schon ziemlich blöd anstellen, um sie zuzulassen. Nutzt Du auch ein ORM, oder bist Du eher der „Ich code alles selbst“ Typ?