Umstieg auf .NET Core, Teil 5: Datenzugriff auf .NET Core umstellen

Seite 2: Entity Framework 6.3 und 6.4

Inhaltsverzeichnis

Für das ADO.NET Entity Framework bietet Microsoft seit 2016 einen Nachfolger an: das Entity Framework Core. Dieser OR-Mapper ist komplett neu geschrieben und versteht sich nicht als vollständig kompatible Nachfolgeversion. Beim klassischen Entity Framework sollte die Version 6.2 vom 26. Oktober 2017 die letzte Version sein.

Doch Microsoft hat sich auch hier umentschieden: Am 23. September 2019 erschien das alte ADO.NET Entity Framework als Version 6.3 auch für .NET Core – im Dezember folgte die Version 6.4. Beide Versionen laufen auf .NET Core 3.0 und 3.1 nicht nur auf Windows, sondern auch auf Linux und macOS. Diese Strategieanpassung ist aber nicht als grundsätzlicher Richtungswechsel misszuverstehen: Microsoft sieht weiterhin die Zukunft in Entity Framework Core, will aber mit dem klassischen Entity Framework in Version 6.3/6.4 für Anwendungen, die Entity Framework einsetzen, den Umstieg von .NET Framework auf .NET Core erleichtern.

Mit dem ADO.NET Entity Framework 6.3/6.4 können Entwickler nun vorhandenen Datenzugriffscode in die Core-Welt übernehmen. Neben einer Aktualisierung der EntityFramework.dll via NuGet sind dafür auch neue Entity-Framework-Treiber notwendig. Funktional gibt es jedoch eine temporäre und zwei dauerhafte Einschränkungen.

Dauerhafte Änderungen:

  1. Die Geodaten Geography und Geometry lassen sich nicht in SQL Server verwenden. Spalten dieses Typs werden beim Laden und Speichern ignoriert.
  2. Es gibt keinen Entity-Framework-Treiber fĂĽr SQL Server Compact.

Die temporäre Einschränkung betrifft nur Nutzer, die mit Database First oder Model First gearbeitet haben, nicht aber Code-First-Anwender: Der grafische Designer für die EDMX-Dateien funktioniert noch nicht in .NET-Core- und .NET-Standard-Projekten. Wer bisher den EDMX-Designer genutzt hat, muss sich mit dem gleichen Verlinkungs-Trick behelfen wie bei Windows Forms und die EDMX-Dokumente noch in einem klassischen .NET-Framework-Projekt gestalten, bevor er das Ergebnis dann in .NET Core verlinkt.

ADO.NET Entity Framework 6.3/6.4 sollte man aber nicht mehr für neue Projekte verwenden, da Microsoft keine neuen Funktionen nachliefern will. Die Versionen 6.3/6.4 lassen sich aber auch in klassischen .NET-Framework-Projekten installieren. Dazu gibt es auf NuGet.org die Abhängigkeiten ".NET Framework 4.0" und ".NET Framework 4.5" (was auch neuere Versionen wie 4.6, 4.7 und 4.8 einschließt). Die Aktualisierung eines klassischen .NET-Framework-Projekts auf Entity Framework 6.4 ist sinnvoll, weil Letzteres einige Fehlerbehebungen enthält.

Im Zuge einer Umstellung von klassischem .NET Framework auf .NET Core lässt sich eine Datenzugriffsschicht zwischen beiden Welten teilen, ohne den sonst notwendigen Weg über ein .NET-Standard-Projekt. Dabei droht jedoch eine Sackgasse, denn Entity Framework 6.3/6.4 gibt es nur für .NET Standard 2.1. Das klassische .NET Framework ist aber auch in der neuesten Version 4.8 bei .NET Standard 2.0 eingefroren worden (laut Ankündigung vom 5. November 2018).

Mit einem Trick lässt sich diese Hürde jedoch überwinden: Statt auf .NET Standard lässt man die Datenzugriffsschicht auf einer klassischen .NET-Framework-Klassenbibliothek (DLL) basieren. Das so entstehende Projekt lässt sich in anderen klassischen .NET-Framework-Projekten referenzieren, auch in .NET-Core-Projekten. Grundsätzlich können Entwickler klassische .NET Framework Assemblies in .NET-Core-Projekte einbinden. Sie funktionieren dort, solange nicht eine Klasse oder ein Klassenmitglied aufgerufen wird, die es in .NET Core nicht gibt (s. Abb. 1). Diese Brücke hat Microsoft gebaut, um auch ältere .NET-Bibliotheken in .NET Core nutzbar zu machen, für die es kein Neukompilat in .NET Standard oder .NET Core gibt.

Nutzbarkeit von Assemblies in .NET Framework und .NET Core (Abb. 1)

(Bild: Dr. Holger Schwichtenberg/www.IT-Visions.de)

Wer im Zuge des Umstiegs vom klassischen .NET Framework auf .NET Core mit dem Gedanken spielt, auch gleich vom klassischen Entity Framework auf Entity Framework Core umzustellen, sollte sich die Unterschiede vor Augen führen: Abbildung 2 stellt den Funktionstand grafisch dar. Zwar hat Microsoft im Verlauf der Versionen von 1.1 bis 3.1 viele gegenüber dem klassischen Entity Framework fehlende Funktionen wieder in Entity Framework Core ergänzt, aber es bleibt auch heute noch eine Lücke, die sich in zwei Gruppen unterteilt:

  • Funktionen, die laut AnkĂĽndigung des Herstellers endgĂĽltig entfallen sollen, und
  • Funktionen, die Microsoft in Entity Framework Core 5.0 (dem Nachfolger der aktuellen Version 3.1) und höher noch nachrĂĽsten will.

Funktionsvergleich zwischen Entity Framework und Entity Framework Core (Abb. 2)

(Bild: Dr. Holger Schwichtenberg/www.IT-Visions.de)

Zur ersten Gruppe zählen insbesondere die EDMX-Dateien mit dem zugehörigen grafischen Designer, die damit verbundenen Vorgehensmodelle Database First und Model First, die älteren Basisklassen ObjectContext und EntityObject sowie die Abfragesprache Entity SQL. In Entity Framework Core können Entwickler nur noch LINQ und SQL sowie Stored Procedures und Table Valued Functions nutzen.

In die zweite Gruppe gehören folgende Entity-Framework-Funktionen:

  • UnterstĂĽtzung fĂĽr Vererbungsabbildung nach dem Table-per-Type-Prinzip (TPT), bei der es fĂĽr jede Klasse in der Vererbungshierarchie genau eine Datenbanktabelle gibt. Entity Framework unterstĂĽtzt nur TPH (Type per Hierarchy) und partiell Type per Concrete Type (TCT).
  • Abstraktion von n:m-Zwischentabellen im Objektmodell. Während das klassische Entity Framework die n:m-Zwischentabellen wegabstrahiert und eine echte n:m-Beziehung im Objektmodell erlaubt, erscheinen bei Entity Framework Core die Zwischentabellen als eigene Klassen im Objektmodell, sodass zwei 1:n-Abbildungen zur Navigation notwendig sind.
  • Die einfache Möglichkeit, zur Laufzeit zu einer LINQ-Abfrage den zugehörigen SQL-Befehl zu erhalten
  • Mapping der Ergebnisse von SQL-Abfragen und Stored-Procedure-Aufrufen auf primitive Datentypen
  • Reverse Engineering bestehender Stored Procedures in der Datenbank
  • Generierung von SQL-Code fĂĽr Stored Procedures fĂĽr die Fälle Create, Update und Delete (CUD) aus dem Code heraus
  • Automatische Validierung der Entitätsobjekte vor dem Speichern
  • Partielle Aktualisierung des generierten Programmcodes beim Reverse Engineering, wenn es Ă„nderungen in der Datenbank gibt

An den ersten drei Punkten arbeitet Microsoft für Entity Framework Core 5.0 bereits – das soll aber erst im November 2020 erscheinen.