Mein Name ist Legion – denn ich bin viele.
Nein – keine Angst – ich leide nicht unter ‘Multipler Persönlichkeitsstörung‘, nein so lauteten die einleitenden Worte von Ralf Westphal zum gestrigen dotnet.pro persistence.day II in Karlsruhe. Denn Datenpersistierung hat heute viele Gesichter – und aus diesem Grunde bin ich ‘runter gefahren und habe mir den Tag über Vorträge zum Thema Objekt-Relationales-Mapping unter :NET angehört.
Vorgestellt wurden u.a. die ORM-Frameworks Opf3, NDO und OpenAccess.
Ich persönlich bin zwiegespalten im Hinblick auf den Einsatz solcher ORM-Frameworks, so verbindet diese Technik zwar die Welt der relationalen Datenhaltung mit der der objektorientierten Programmierung, allerdings muss man sich auch über die Nachteile, die diese Technik mit sich bringt im Klaren sein und somit abwägen, wozu die entwickelte Software dienen soll und ob ein ORM-Einsatz Sinn macht.
Sicherlich bietet die Technik mit Lazy Loading den Vorteil nicht direkt alle Daten in die unverbundene .NET Welt zu laden, sondern nach dem Motto ‘on demand’ diese Daten zu beschaffen, allerdings setzt dies, wie in den meisten vorgestellten ORM-Frameworks, eine konstante Verbindung zur Datenbank vorraus. Auch ist es für den Entwickler sehr viel plastischer die abhängigen Daten über Properties abzurufen als über weitere Datenbank-Abfragen und Joins (Beispiel Rechnung -> Rechnungszeilen). Allerdings werden die Nachteile sehr schnell klar, wenn Massendaten verarbeitet werden sollen. (z.B.: alle Rechnungen vor dem 12.04.2006) Da es nicht sinnvoll ist erst alle Objekte zu instantiieren bieten die Frameworks hier zwar Query-Funktionen, doch ich halte dies für einen Bruch im Konzept. Geht es um reine Datenpflege, halte ich den ADO.NET Ansatz mit DataSet und DataTable (also der Speicherabbildung der Datenbank) für den richtigen Ansatz, da auch hier Business-Logik (welche beim ORM-Ansatz im Objekt liegt) an zentraler Stelle (in der Datenbank oder auf dem ApplicationServer) abgelegt werden kann. Arbeitet man konsequent über mehrere View-Schichten, sehe ich zum Client hin meine Tabellen als die Objekt-Represäntation und die View-Schichten bilden meine Polymorphie mit ihrer Logik ab.
Da wir zur Zeit auch mit Performance-Problemen zu kämpfen haben, sollten wir dennoch auch einmal diese Ansätze mit einbeziehen – mal schauen wo die Reise hingeht 
P.S.: Eine schöne Übersicht der am Markt befindlichen Werkzeuge findet man hier: How-To-Select an Object-Relational Mapping Tool for .NET
Also mit den multiplen Persönlichkeiten sollten wir uns nochmal unterhalten.
bis später