Verwirrung um ORM: LINQ-to-SQL oder ADO.NET Entity Framework?
Lange Zeit bot Microsoft gar keine objekt-relationalen Mapper für .NET an, nun sind es gleich zwei.
- Dr. Holger Schwichtenberg
- Christian Kirsch
10 wichtige Fragen zu .NET
In dieser zehnteiligen Serie liefert .NET-Experte Holger Schwichtenberg Antworten auf die am häufigsten gestellten Fragen, die .NET-Entwickler beschäftigen.
- .NET 2.0 oder .NET 3.5?
- VB oder C#?
- Express oder Professional?
- Windows Forms oder WPF?
- LINQ-to-SQL oder ADO.NET Entity Framework?
Während in der Java-Welt das objekt-relationale Mapping (ORM) schon lange zu den etablierten Techniken gehört, hat Microsoft diesen Trend lange verschlafen beziehungsweise nicht vermocht, ein geeignetes Produkt zur Marktreife zu führen. Bis zum .NET Framework 3.5 gab es daher kein eigenes produktionstaugliches ORM-Werkzeug. ADO.NET beschränkt sich auf den direkten, tabellenorientierten Datenzugriff und die Abbildung zwischen XML-Dokumenten und dem relationalen Modell. Mehr als 20 Fremdwerkzeuge teilten sich daher bis dahin den ORM-Markt für .NET. Bekannte Drittanbieterprodukte sind das freie NHibernate (eine Portierung aus der Java-Welt), Teleriks Open Access (früher Vanatec Open Access, auch aus der Java-Welt), .NET Data Objects (NDO) und Genome. Die letzten drei sind im deutschsprachigen Raum deswegen besonders bekannt, weil die Anbieter in Deutschland bzw. Österreich sitzen.
Verwirrungen seit 2003
Zwar gab es im Jahr 2003 die Alpha-Version eines OR-Mappers unter dem Codenamen Object Spaces, der auch in den ersten Vorabversionen von .NET 2.0 steckte, aber er schaffte es nicht zur Marktreife. Die endgültigen Versionen von .NET 2.0 und 3.0 enthielten weder Object Spaces noch ein anderes ORM-Werkzeug. Grund für das Scheitern war nicht nur das Lehrgeld, das Microsoft zahlen musste, sondern auch, dass damals ein ähnliches Konzept für das datenbankorientierte Dateisystem WinFS realisiert werden sollte. Das inzwischen vorerst »beerdigte« Produkt sollte nicht nur Dateien, E-Mails und Kontakte ablegen können, sondern auch beliebige andere .NET-Objekte. Zwei ähnliche Produkte ergaben damals für die Redmonder Chefetage keinen Sinn.
Kurioserweise gibt es nun im Jahr 2009 trotzdem zwei OR-Mapper von Microsoft für .NET: LINQ-to-SQL (vom C#-Entwicklungsteam) und die ADO.NET Entity Framework Object Services (vom ADO.NET-Entwicklungsteam). LINQ-to-SQL ist im November 2007 als fester Bestandteil des .NET Frameworks 3.5 erschienen. Das ADO.NET Entity Framework (EF) und die zugehörigen Object Services liefert Microsoft hingegen erst mit .NET 3.5 Service Pack 1 aus.
Trotz der getrennten Entwicklungslinien weisen LINQ-to-SQL und das ADO.NET Entity Framework gewisse Ähnlichkeiten auf. In beiden hält ein sogenannter Kontext (LINQ-to-SQL: "Datenkontext", EF: "Objektkontext") die Objekte zusammen und bietet den Einstiegspunkt für Abfragen. Beide ORM-Werkzeuge unterstützen LINQ. Ein wesentlicher Unterschied, der viele Entwickler verwirrt, besteht aber schon in der Abgrenzung der beiden Begriffe: LINQ-to-SQL bezeichnet sowohl das ORM-Werkzeug mit der Mapping-Sprache als auch die Anwendung der LINQ-Syntax auf diese Abbildungen. EF ist hingegen ein Oberbegriff für das ORM-Werkzeug "Object Services", die Abbildungssprache "Entity Data Model" sowie die Abfragesprachen "Entity SQL" und "LINQ-to-Entities".
