Erklärung des Begriffs: ADO.NET Entity Framework (EF)

• ADO.NET Entity Framework 1.0 ist erschienen am 14.08.2008 (in .NET Framework 3.5 Service Pack 1)
• ADO.NET Entity Framework 4.0 ist erschienen am 12.04.2010 (in .NET Framework 4.0. Eine Version 2.0 und 3.0 gab es nie!)
• ADO.NET Entity Framework 4.1 ist erschienen am 13.04.2011 (Erweiterung auf nuget.org zu dem in .NET Framework 4.x veröffentlichten Entity Framework)
• ADO.NET Entity Framework 4.2 ist erschienen am 01.11.2011 (Erweiterung auf nuget.org zu dem in .NET Framework 4.x veröffentlichten Entity Framework)
• ADO.NET Entity Framework 4.3 ist erschienen am 09.02.2012 (Erweiterung auf nuget.org zu dem in .NET Framework 4.x veröffentlichten Entity Framework)
• ADO.NET Entity Framework 4.4 ist erschienen am 11.08.2012 (Erweiterung auf nuget.org zu dem in .NET Framework 4.x veröffentlichten Entity Framework)
• ADO.NET Entity Framework 5.0 ist erschienen am 11.08.2012 (Erweiterung auf nuget.org zu dem in .NET Framework 4.5 und höher veröffentlichten Entity Framework / wurde nicht nur über Nuget, sondern auch mit Visual Studio 2012 ausgeliefert)
• ADO.NET Entity Framework 6.0 ist erschienen am 17.10.2013 (Erweiterung auf nuget.org zu dem in .NET Framework 4.x veröffentlichten Entity Framework / wird nicht nur über Nuget, sondern auch mit Visual Studio 2013 und höher ausgeliegert)
• ADO.NET Entity Framework 6.1 ist erschienen am 17.03.2014 (Erweiterung auf nuget.org zu dem in .NET Framework 4.x veröffentlichten Entity Framework)
• ADO.NET Entity Framework 6.2 ist erschienen am 26.10.2017 (Erweiterung auf nuget.org zu dem in .NET Framework 4.x veröffentlichten Entity Framework)
• ADO.NET Entity Framework 6.3 ist erschienen am 23.09.2019 (Erweiterung auf nuget.org zu dem in .NET Framework 4.x veröffentlichten Entity Framework, läuft nun auch auf .NET Core)
• ADO.NET Entity Framework 6.4 ist erschienen am 03.12.2019 (Erweiterung auf nuget.org zu dem in .NET Framework 4.x veröffentlichten Entity Framework, läuft nun auch auf .NET Core)

• 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 nur Microsoft SQL Server. Für das Entity Framework ist Unterstützung für viele Datenbanken angekündigt.
• LINQ-to-SQL bietet als Abfragesprache LINQ oder direktes SQL. Das Entity Framework 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 nur die 1:1-Abbildung zwischen Tabellen und Objekten. Das Entity Framework unterstützt beliebige Abbildungen.
• 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 Entity Framework hier von dem Entwickler verlangt, diese explizit per Code anzufordern. Hingegen hat das Entity Framework 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 Entity Framework 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. Entity Framework 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.

• Unterstützung für Forward Engineering/Code-First (Erzeugen der Datenbank auf Basis des Models aus dem Designer heraus. Aber kein Round Trip Engineering bei Veränderungen, d.h. Dann muss die Datenbank erst komplett gelöscht werden)
• Persistence Ignorance: Unterstützung für ORM mit POCOs
• Berechnete Eigenschaften (Model Definied Functions)
• Implizites Nachladen (Lazy Loading)
• Einfacheres Anpassen der Codegenerieren (Codegeneration ist ein Workflow der Windows Workflow Foundation)
• Unterstützung für Table Valued Functions (TVF)
• …

ADO.NET Entity Framework versus Dataset

• Der Objektcontainer sind nicht von Dataset abgeleitet; es ist sogar möglich, ganz einfache .NET-Klassen (sogenannte Plain Old CLR Objects – POCO) zu verwenden, die gar keine Basisklasse besitzen.
• LINQ-Befehle werden nicht auf geladenen Objekten im RAM ausgeführt, sondern in den meisten Fällen in SQL-Befehle umgesetzt und direkt in der Datenbank ausgeführt.
• Die Programmierung ist insgesamt eleganter und prägnanter.