OR Mapper werden in heutzutage in vielen Softwareprojekten benutzt. Als ich noch am Tech war, entstanden gerade die ersten OR Mapper, bzw. ORM Frameworks. Dazumal fand ich das Konzept ziemlich toll. Ich musste mich nicht mehr mit SQL rumschlagen. Ehrlich gesagt, habe ich noch nie eine Affinität zu DB’s und SQL und Stored Procedures etc. gehabt. Und eine Abstraktionsschicht welche mir das alles abnahm fand ich schon toll.
Tja jetzt ein paar Jahre später durfte ich doch die eine oder andere Erfahrung mit Hibernate, NHibernate und Entity Framework machen. Erst letzte Woche habe ich laut geflucht, als ich herausfand, dass ein Nullable Foreign Key einfach wieder auf Null gesetzt wird, wenn der Wert des Keys sich nicht ändert. Man muss also ein doppeltes “update” fahren, damit der Null – Wert wieder auf den “richtigen” Wert zurückgeschrieben wird. Sehr logisch. Bin begeistert.
Im Zuge der Frustbewältigung, kam mir in den Sinn, dass es schon seit ein paar Jahren Leute gibt, welche ORM kritisieren. So Hat z.B. Jeff Atwood schon 2006 postuliert: “Object-Relational Mapping is the Vietnam of Computer Science“. Oder aber auch der Blog post auf seldo.com der da hiess: “ORM is an anti-pattern“. Und auch ich glaube mittlerweile die haben recht.
Ja ich hasse SQL. Aber im Gegensatz zu einem ORM weiss ich wenigstens dass ich der Depp war, welcher die falschen Statements geschrieben hat. Und warum. Ein ORM tut manchmal einfach etwas und alle schütteln dann den Kopf. Ein klassischer SQL Persistenzlayer mag nichts “schönes” sein. Aber es funktioniert. Es gibt mittlerweile einVersprechen von ORM dass ich definitiv nicht mehr glaube.
Ein ORM spart Zeit und Geld in der Entwicklung
So ein Blödsinn. Erstens braucht es immer mindestens einen Engineer, welcher ein Spezialist für den Mapper ist. Ein Mapper bildet nicht alle benötigte Funktionalität einfach so ab (z.B. N:M Abhängigkeiten). Und wehe etwas passt nicht oder “merkwürdige Effekte” treten auf. Dann hat man schnell mal ein paar Personenmonate für’s Mapping verhauen. Wo ist denn die Entwicklung einfacher geworden? Früher musste ich die entsprechnede Funktion im Persistenzlayer aufrufen. Heute muss ich zuerst mal ein Mapping definieren (und das muss man auch richtig tun), dann den entsprechenden Adpater schreiben und mich noch mit einem DbContext, Session handling und Lazy Loading herumschlagen. Wo habe ich da Zeit gespart?
Ach ja und das tolle Argument: “Man kann einfach zwischen Oracle und MS SQL etc. wechseln.” Die Software muss ja auf jeder noch so möglichen DB laufen. Nach 10 Jahren als professioneller Hacker und drei Produkten am Markt, sowie meheren kleinen Projekten: ICH HABS NOCH NIEEEEEEEE GEBRAUCHT! Entweder Oracle oder MS SQL. Punkt. Das braucht es nur für ganz spezielle Projekte. Und die sollen sich mal überlegen wozu. Um den 2000 Kunden, welcher unbedingt eine andere DB braucht zu unterstützen?
Nee. NoSQL ist wahrscheinlich auch nicht die Lösung. Aber ORM ist überhaupt keine Lösung. Ich möchte doch nur ein LSD – Repository. Load, Store, Delete. Mehr braucht es nicht. Ich habe meine Objektbäume, die müssen persistiert werden und Punkt. Wenn klassische DB’s das so nicht können, dann sind sie ungeeignet. Bzw. die Konzepte E/R und OO passen nicht zueinander. Aber da Tage und Monate verbraten, nur um den ORM zu beherrschen, da ist mir ein SQL Persistenzlayer lieber.

