Sie sind hier: Startseite | Wissen
BASTA 2016
Begriff ADO.NET Entity Framework
Abkürzung EF
Eintrag zuletzt aktualisiert am 05.08.2014

 Zur Stichwortliste unseres Lexikons

Was ist ADO.NET Entity Framework?

ADO.NET Entity Framework ist ein Objekt-Relationaler Mapper (ORM) zur Abbildung von relationalen Datenbanktabelle auf .NET-Objektstrukturen.

Versionsgeschichte

Ursprünglich sollte das ADO.NET Entity Framework schon mit .NET 3.5 erscheinen, das Projekt verspätete sich jedoch.
1.0: Microsoft lieferte das ADO.NET Entity Framework erstmals mit .NET 3.5 Service Pack 1 und Visual Studio 2008 Service Pack 1 aus.
4.0: In .NET 4.0 und Visual Studio 2010 war die zweite Version des ADO.NET Entity Framework enthalten mit der Versionsnummer 4.0. In dieser Version gibt es erhebliche Erweiterungen und Verbesserungen.
Seit Version 4.1 ist das Entity Framework von .NET entkoppelt und hat eigene Release-Zyklen. Entity Framework ist nun ein Open Soure-Projekt wird über nuget.org verbreitet.
5.0 für .NET 4.5 (bzw. 4.4 für .NET 4.0): wurde nicht nur über Nuget, sondern auch mit Visual Studio 2012 ausgeliegert
6.x für .NET 4.5 und .NET 4.0): wurde nicht nur über Nuget, sondern auch mit Visual Studio 2013 ausgeliegert

ntity Framework 7 wird einige gravierende Änderungen gegenüber der Version 6.x beinhalten. Der OR-Mapper wird leichtgewichter werden, sodass er auch auf Windows Phone läuft. Und er soll flexibler werden, sodass auch NoSQL-Datenbanken damit angesprochen werden können. Microsoft hatte dies auf der TechEd USA bekanntgegeben. Ausprobieren kann man EF 7 im Rahmen der Visual Studio "14"-Vorabversion. Die Flexibilisierung geht einher mit vielen Änderungen unter der Haube und an den APIs. So wird es den ObjectContext nicht mehr geben, nur noch DbContext als Basisklasse für Kontextklassen.

Informationen zum ADO.NET Entity Framework

Die zentrale Datenzugriffsschnittstelle in .NET ist seit .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 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 arbeitet direkt auf dem Datenbankschema, nicht auf dem konzeptuellen Modell, das bei der Entity-Relationship-Modellierung (ERM) verwendet wird. Das Entity Framework hingegen bietet das gleiche Abstraktionsniveau wie die ERM.

Vergleich LINQ-to-SQL und die ADO.NET Entity Framework Object Services

LINQ-to-SQL und die ADO.NET Entity Framework Object Services weisen trotz der getrennten Entwicklungslinien gewisse Ähnlichkeiten auf. In beiden Architekturen hält ein sogenannter Kontext (LINQ-to-SQL: »Datenkontext«, Entity Framework: »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 und dem ADO.NET Entity Framework sind aber:
  • 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.

Entity Framework Version 4 in .NET 4.0:

  • 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

Beim ADO.NET Entity Framework sind transportieren typisierte Objekte die Daten, bei der direkten Arbeit mit ADO.NET Datasets sind diese untypisiert. Untypisierte Objektcontainer haben den Nachteil, dass man Typkonvertierungen zwischen Datenbankdatentypen und .NET-Datentypen selbst vornehmen muss. Auch muss man den "null"-Fall abfangen (vgl. die bereits in diesem Buch in Kapitel TODO aufgezeigten Herausforderung bez. DBNull und Nothing).
Ein vergleich in der gleichen "Liga" wäre damit das ORM mit dem typisierten Dataset zu vergleichen. Auch hier bietet das Entity Framework einige Vorteile:
  • 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.

Artikel in gedruckten Medien

  Lauschangriff auf SQL
 (DotNetPro - Das .NET-Magazin für Entwickler, 2014)
  Erste Beta-Version von Entity Framework 6.1
 (Heise.de, 2014)
  Klar abbilden: Objekt-Relationales Mapping mit Microsofts Entity Framework 6.0
 (iX - Magazin für professionelle Informationstechnik, 2014)
  Vergleichsweise Langsam
 (DotNetPro - Das .NET-Magazin für Entwickler, 2014)
  Die Datenbank-Konsole: LINQPad
 (DotNetPro - Das .NET-Magazin für Entwickler, 2014)
  Asynchrone Datenbankzugriffe mit Microsofts Entity Framework 6.0
 (Heise Developer, 2013)
  Migrationsherausforderungen: Das Entity Framework ist nun ganz von .NET Framework entkoppelt
 (DotNetPro - Das .NET-Magazin für Entwickler, 2013)
  Daten-Power in der Shell: ADO.NET und Entity Framework in der Windows PowerShell
 (DotNetPro - Das .NET-Magazin für Entwickler, 2012)
  Hü und Hott: Schemamigrationen mit ADO.NET-Entity Framework 4.3
 (DotNetPro - Das .NET-Magazin für Entwickler, 2012)
  Datenbankprogrammierung mit .NET 4.5. Mit Visual Studio 2012 und SQL Server 2012
 (Datenbankprogrammierung mit .NET 4.5, 2012)
  Vorsorgliche Datenhaltung: Ladestrategien im ADO.NET Entity Framework
 (DotNetPro - Das .NET-Magazin für Entwickler, 2012)
  Vorauschauende Kontrolle: Validierung von Entity Framework-Objekten
 (DotNetPro - Das .NET-Magazin für Entwickler, 2012)
  Viele kleine Schritte: ADO.NET Entity Framework 4.5
 (DotNetPro - Das .NET-Magazin für Entwickler, 2012)
  Datenbankprogrammierung mit .NET 4.0. Mit Visual Studio 2010 und SQL Server 2008 R2
 (Datenbankprogrammierung mit .NET 4.0. Mit Visual Studio 2010 und SQL Server 2008 R2, 2011)
  Verteilte Entitäten - Entity Framework in verteilten Systemen mit WCF
 (DotNetPro - Das .NET-Magazin für Entwickler, 2011)
  Massenbewegung - Große Menge von Datensätzen importieren und ändern
 (DotNetPro - Das .NET-Magazin für Entwickler, 2011)
  Kolumne: .NETversum – Tipps und Tricks rund um .NET und Visual Studio - Ausgabe 12/2011
 (Windows Developer (vormals: dot.NET Magazin), 2011)
  Der Dritte weg - ADO.NET Entity Framework Version 4.1: das Code-Only-Verfahren
 (DotNetPro - Das .NET-Magazin für Entwickler, 2011)
  Viele Pfade - Datenzugriff in ASP.NET-Anwendungen
 (DotNetPro - Das .NET-Magazin für Entwickler, 2011)
  Abhöranlage - ADO.NET Entity Framework Profiler
 (DotNetPro - Das .NET-Magazin für Entwickler, 2011)
  Doppelt hält besser - ADO.NET Entity Framework 4.1 - ADO.NET Entity Framework Version 4.1: das neue DbContext-Objekt
 (DotNetPro - Das .NET-Magazin für Entwickler, 2011)
  Schlingerkurs - Microsofts Datenzugriffstrategie
 (DotNetPro - Das .NET-Magazin für Entwickler, 2011)
  Laden ohne Balast - „No Tracking“-Abfragen für erhebliche Leistungsoptimierung im ADO.NET Entity Framework
 (DotNetPro - Das .NET-Magazin für Entwickler, 2011)
  Erste Oracle-Unterstützung für Entity Framework
 (Heise Developer, 2011)
  Verteilte Systeme und Services mit .NET 4.0
 (Verteilte Systeme und Services mit .NET 4.0, 2011)
  Programmieren mit dem ADO.NET Entity Framework
 (Programmieren mit dem ADO.NET Entity Framework, 2011)
  Im Prinzip POCO - Persistence Ignorance im ADO.NET Entity Framework
 (DotNetPro - Das .NET-Magazin für Entwickler, 2011)
  .NET 4.0 Update
 (.NET 4.0 Update, 2010)
  Visual Basic 2010: Grundlagen, ADO.NET, Windows Presentation Foundation
 (Visual Basic 2010: Grundlagen, ADO.NET, Windows Presentation Foundation, 2010)
  .NET 4.0 Crashkurs
 (.NET 4.0 Crashkurs, 2010)
  Deutlich Reifer - ADO.NET Entity Framework 4.0
 (devdorado, 2009)
  10 wichtige Fragen zu .NET, Teil 5: Wege zu den Daten - Verwirrung um objekt-relationale Mapper: LINQ-to-SQL oder ADO.NET Entity Framework?
 (Heise Developer, 2009)
  Die Mühen der Ebene - ADO.NET Entity Framework in der Praxis
 (DotNetPro - Das .NET-Magazin für Entwickler, 2009)
  Die Qual der Wahl: Objektrelationale Mapper für .NET im Vergleich
 (DotNetPro - Das .NET-Magazin für Entwickler, 2008)
  .NET 3.5 Crashkurs
 (.NET 3.5 Crashkurs, 2008)
  Das ADO.NET Entity Framework
 (DotNetPro - Das .NET-Magazin für Entwickler, 2007)

Beratung & Support:

Schulungen zu diesem Thema:

 Anfrage für eine individuelle Schulung zum Thema ADO.NET Entity Framework  Gesamter Schulungsthemenkatalog