Praktisches & Grundsätzliches zur Informatik

Brauchbare OR Mapper

Unter einem OR Mapper versteht man Middleware, die in einer objektorientierten Programmiersprache geschriebener Anwendungscode benötigt, um über ein relationales DBMS verwaltete Daten objektorientiert dargestellt sehen zu können: ganz so als würden sie nur in programmlokalen Variablen existieren.

Solche OR Mapper mussten Anwendungsprogrammierer früher selbst schreiben (als sog. Datenschicht der Anwendung, die zwischen 30 und 60 Prozent der gesamten Anwendung ausmachte).

Heute gibt es applikationsneutrale OR Mapper. Die bekanntesten davon sind:

  • für Java

  • für .NET

    • Dapper: besonders einfacher, extrem schneller OR Mapper für ADO.NET
    • Simple.Data
    • NHibernate (nach .NET portiertes Hibernate, lese HB),
    • ADO.NET Entity Framework (Microsoft), am wenigsten performant, [1] [2]
    • LINQ-to-SQL (Microsoft)
    • F# Type Providers
    • Genome (proprietär, eine LINQ-Anwendung),
    • Invist (Freeware, per MS Visual Studio nutzbar),
    • nHydrate (ebenfalls Open Source, 2011 noch im Entstehen begriffen, lese HB).

      Befürworter von nHydrate vergleichen es mit Microsofts Entity Framework (EF) wie folgt:

      There are many scenarios where EF will be the platform of choice but there is a learning curve to setup your application framework correctly and efficiently. This is not trivial. EF is great at database mapping but default features are sparse. There is a lot of code you will need to write to get a usable framework up and running. nHydrate tries to alleviate this issue by generating code with many of the conveniences that you will need by default. EF is an extensible platform that allows you to build your own framework on top of it. nHydrate tries to get you coding sooner with a smaller learning curve. Both platforms address the repetitive database code that is the bane of all developers. However EF gives you a platform to build a framework whereas nHydrate gives you a framework already built.

      Auch was der Hersteller von Genome sagt, zeigt, dass Microsoft's OR Mapper noch nicht so recht zu einer einzigen glatten Lösung zusammengefunden haben. Ob aber Genome — als ein Produkt, welches weder von Microsoft kommt noch Open Source ist — überleben wird, erscheint mehr als fraglich.

      Da mit LINQ garantiert werden kann, dass jeder Datensatz erst dann zum Client transferiert wird, wenn er dort wirklich gebraucht wird, sollten OR Mapper für .NET sich stets auf LINQ ab­bilden. Vom Konzept her gesehen scheint Hibernate der beste Ansatz.

      Lese auch: OR Mapper für .NET im Vergleich und ADO.NET Entity Framework.

      Hinweis: So wie eben in Form von .NET Core eine nicht mehr an MS Windows gebundene, optimierte Implementierung von .NET entsteht, entsteht parallel dazu auch eine portable Version von Microsofts Entity Framework: Framework Core. Dieser neue OR Mapper wird sich deutlich von seiner alten, nicht portablen Version unterscheiden, scheint aber — ähnlich dem .NET Core — derzeit (2017) noch allzu unfertig [HS].

  • für Scala und die Typesafe Plattform

    • Slick: Functional Relational Mapping for Scala

  • für Python

  • für Javascript und node.js

  • für PHP



In der Summe gilt: Die Datenschicht einer modernen, objektorientiert implementierten Anwendung ist eine i.A. nur noch ganz dünne OR Mapper Anwendung (die aber dennoch automatisch implementiert sein sollte und zwar so, dass automatisches Round Trip Engineering möglich ist, d.h. Fortschreiben des Daten­modells der Anwendung kein manuelles Abändern von Code der Datenschicht erzwingt). Dies zu erreichen ist besonders einfach in .NET, denn da C# partielle Klassen unterstützt, braucht generierter bzw. von Hand geschriebener Code niemals in derselben Datei stehen.


Lies auch:
Wissenswertes zu "Code Generators, Datenschicht, OR Mapper" zusammengestellt durch Gebhard Greiter.
tags: seiteMapperNETMicrosoft: Mapper1gegreit NET1gegreit Microsoft1gegreit