LINQ-to-SQL versus ADO.NET Entity Framework

Der zentrale, neue Baustein in .NET 3.5 Service Pack 1 ist das ADO.NET Entity Framework, das einerseits die bestehende ADO.NET-Infrastruktur auf das Abstraktionsniveau der konzeptionellen Datenmodellierung hievt und andererseits einen weiteren Objekt-Relational Mapper (ORM) anbietet. Das ADO.NET Entity Framework (enthalten in .NET ab Version 3.5 Service Pack 1) ist aber keine Weiterentwicklung des mit .NET 3.5 erschienenen ORM-Werkzeugs LINQ-to-SQL, sondern ein fast komplett anderes (neues) Produkt, das von einem anderen Entwicklungsteam parallel zu LINQ-to-SQL entwickelt wurde und nun hausintern bei Microsoft um die Kunden konkurriert. Das Entity Framework ist entstanden aus dem früheren Ansatz »Object Spaces«.

Das ADO.NET Entity Framework ist eine weitere (kuriose) Episode in der langen Geschichte »Objekt-Relationales Mapping bei Microsoft«. Mit Object Spaces und dem ORM im SQL-Server-basierten Dateisystem WinFS ist Microsoft gescheitert – unter anderem deshalb, weil Object Spaces und WinFS zwei unterschiedliche Ansätze für eine sehr ähnliche Aufgabenstellung waren. Mit dem Entity Framework und dem ORM in LINQ (LINQ-to-SQL) gibt es nun wieder zwei verschiedene Ansätze.

LINQ-to-SQL und die ADO.NET Entity Framework weisen trotz der getrennten Entwicklungslinien gewisse Ähnlichkeiten auf. In beiden Architekturen hält ein sogenannter Kontext (LINQ-to-SQL: »Datenkontext«, EF: »Objektkontext«) die .NET-Objekte zusammen und bietet den Einstiegspunkt für LINQ-Abfragen. LINQ-to-SQL bietet aber insgesamt weniger Optionen als das ADO.NET Entity Framework mit dem dazugehörenden LINQ-Dialekt LINQ-to-Entities.

Wesentliche Unterschiede zwischen LINQ-to-SQL (LTS) und dem ADO.NET Entity Framework (EF) sind: ()

• Für LINQ-to-SQL gilt die Einschränkung, dass Microsoft selbst nur einen Provider für Microsoft SQL Server liefert und durch die Nicht-Offenlegung der Schnittstellen auch verhindern will, dass andere Hersteller Provider entwickeln. Das .NET Entity Framework hingegen hat Microsoft für andere Anbieter geöffnet, sodass hier andere Provider verfügbar sind.
•  LINQ-to-SQL unterstützt (fast) nur die 1:1-Abbildung zwischen Tabellen und Objekten. Das Entity Framework unterstützt beliebige Abbildungen.
• LINQ-to-SQL arbeitet direkt auf dem Datenbankschema, nicht auf dem konzeptuellen Modell, das bei der Entity-Relationship-Modellierung (ERM) verwendet wird. Besonders deutlich wird dies bei N:M-Abbildungen: Im EF kann dies in zwei Klassen abgebildet werden, in LINQ-to-SQL braucht man drei (genausoviele wie Tabellen)!
• LINQ-to-SQL bietet als Abfragesprache LINQ oder direktes SQL. Das EF bietet neben LINQ Entity SQL (eSQL), einen datenbankneutralen SQL-Dialekt, der auf der konzeptuellen Ebene arbeitet, aber nur SELECT-Befehle anbietet.
• LINQ-to-SQL unterstützt Vererbung nur mit einer Tabelle mit Diskriminatoren (Filtered Mapping). Das Entity Framework unterstützt beliebige Abbildungen und auch horizontales und vertikales Mapping.
• Das ADO.NET Entity Framework unterstützt Mapping auch auf Tabellenebene (d.h. auch ohne Objekt-Relationales Mapping). LINQ-to-SQL bietet das nicht.
• LINQ-to-SQL unterstützt neben Reverse Engineering (d.h. die Erstellung von Geschäftsobjekten aus Datenbanken) auch Forward Engineering (d.h. die Erstellung der Datenbank aus Geschäftsobjekten). Das ADO.NET Entity Framework unterstützt kein Forward Engineering, sondern nur Reverse Engineering.
• Das ADO.NET Entity Framework bietet im Gegensatz zu LINQ-to-SQL die Serialisierung kompletter Objektbäume. Bei LINQ-to-SQL sind Assoziationen nicht serialisierbar.
• Beide Modelle verwenden in der Grundeinstellung Lazy Loading und bieten optional Eager Loading. Beim Lazy Loading lädt LINQ-to-SQL die verbundenen Objekte automatisch bei Bedarf, während das EF hier von dem Entwickler verlangt, diese explizit per Code anzufordern. Hingegen hat das EF wieder den Vorteil, dass man Eager Loading für jede einzelne Abfrage definieren kann, während in LINQ-to-SQL diese Einstellung global für den Datenkontext vorhanden ist.
• Der Objekt-Relationale Designer ist in beiden Fällen anders. Der LINQ-to-SQL-Designer erzeugt .dbml-Dateien, der EDM-Designer .edmx-Dateien. Das verwendete XML-Format ist ganz verschieden.
• Die Geschäftsobjekte im EF brauchen die Klasse System.Data.Objects.DataClasses.EntityObject als Basisklasse. Hier ist LINQ-to-SQL flexibler, weil keine Basisklasse benötigt wird.
• In LINQ-to-SQL kann man das Mapping wahlweise im Programmcode durch Annotationen oder in einer externen XML-Datei erstellen. EF unterstützt nur das Mapping durch XML-Dateien.
• Mithilfe eines weiteren Bausteins, den ADO.NET Data Services, kann man LINQ-to-Entities-Abfragen über Webservices an ein entferntes System senden und dort ausführen lassen. Für LINQ-to-SQL gibt es diese Möglichkeit nicht.
• Auf der Ebene der Programmierschnittstelle gibt es Unterschiede, z. B. SubmitChanges() in LINQ-to-SQL entspricht SaveChanges() im ADO.NET Entity Framework.