Plan für Entity Framework Core 5.0
Wichtig
EF Core 5.0 wurde veröffentlicht. Diese Seite bleibt als historische Aufzeichnung des Plans.
Wie im Planungsprozessbeschrieben, haben wir Eingaben von Projektbeteiligten zu einem vorläufigen Plan für die EF Core 5.0-Version gesammelt.
Wichtig
Dieser Plan ist noch in Bearbeitung. Nichts hier ist ein Engagement. Dieser Plan ist ein Ausgangspunkt, der sich weiterentwickeln wird, wenn wir mehr erfahren. Einige Dinge, die derzeit nicht für 5.0 geplant sind, werden möglicherweise eingezogen. Einige Dinge, die derzeit für 5.0 geplant sind, könnten möglicherweise verschoben oder ausgeschlossen werden.
Allgemeine Informationen
Versionsnummer und Veröffentlichungsdatum
EF Core 5.0 soll zusammen mit .NET 5.0 veröffentlicht werden. Die Version "5.0" wurde für die Ausrichtung an .NET 5.0 ausgewählt.
Unterstützte Plattformen
EF Core 5.0 ist für die Ausführung auf einer beliebigen .NET Standard 2.1-Plattform geplant, einschließlich .NET 5.0. Dies ist Teil der allgemeineren .NET-breiten Konvergenz von Plattformen zu .NET Core.
EF Core 5.0 wird nicht unter .NET Framework ausgeführt.
Breaking Changes
EF Core 5.0 wird einige Breaking Changes enthalten. Diese werden jedoch weniger gravierende Auswirkungen als bei EF Core 3.0 haben. Unser Ziel ist es, die große Mehrheit der Anwendungen ohne Unterbrechung zu aktualisieren.
Es wird erwartet, dass es einige grundlegende Änderungen für Datenbankanbieter geben wird, insbesondere im Zusammenhang mit der TPT-Unterstützung. Wir erwarten jedoch, dass die Arbeit, einen Anbieter für 5.0 zu aktualisieren, kleiner ist als für das Update für 3.0 erforderlich.
Designs
Wir haben einige wichtige Bereiche oder Themen extrahiert, die die Grundlage für die großen Investitionen in EF Core 5.0 bilden werden.
Vollständig transparente m:n-Zuordnung nach Konvention
Leitende Entwickler: @smitpatel, @AndriySvyrydund @lajones
Nachverfolgbar über #10508
T-Shirt-Größe: L
Status: Fertig
Many-to-Many ist das am häufigsten angeforderte Feature (, ca. 506 Stimmen) im GitHub-Backlog.
Die Unterstützung für m:n-Beziehungen kann in drei Hauptbereiche aufgeteilt werden:
- Das Überspringen von Navigationseigenschaften wird im nächsten Artikel behandelt.
- Entitätstypen für Eigenschaftenbehälter. Diese ermöglichen die Verwendung eines standardmäßigen CLR-Typs (z. B.
Dictionary
) für Entitätsinstanzen, sodass für jeden Entitätstyp kein expliziter CLR-Typ erforderlich ist. Nachverfolgbar über #9914 - Sugar für die einfache Konfiguration von m:n-Beziehungen
Nicht nur das Überspringen von Navigationseigenschaften wird unterstützt, sondern auch folgende weitere Bereiche von m:n werden in EF Core 5.0 integriert, damit Sie diese Option vollständig nutzen können.
M:n-Navigationseigenschaften (auch bekannt als „Navigationen überspringen“)
Leitende Entwickler: @smitpatel und @AndriySvyryd
Nachverfolgbar über #19003
T-Shirt-Größe: L
Status: Fertig
Wie im ersten Thema beschrieben, hat die viele-zu-viele Unterstützung mehrere Aspekte. In diesem Artikel wird insbesondere die Verwendung des Features zum Überspringen von Navigationseigenschaften nachverfolgt. Unserer Meinung nach liegt der Wunsch nach m:n-Unterstützung hauptsächlich daran, dass bei Geschäftslogik wie Queries bisher keine Möglichkeit besteht, die „natürlichen“ Beziehungen zu verwenden, ohne auf die Jointabelle verweisen zu müssen. Der Entitätstyp der Verknüpfungstabelle ist möglicherweise noch vorhanden, sollte aber die Geschäftslogik nicht beeinträchtigen.
Tabelle-pro-Typ-Vererbungszuordnung (TPT)
Leitender Entwickler: @AndriySvyryd und @smitpatel
Nachverfolgbar über #2266
T-Shirt-Größe: XL
Status: Fertig
Wir implementieren TPT, da es sich sowohl um eine sehr angeforderte Funktion handelt (circa 289 Stimmen; 3. insgesamt) und weil es einige geringfügige Änderungen erfordert, die wir für die grundlegende Struktur des gesamten .NET 5-Plans als geeignet erachten. Wir erwarten, dass dies zu notwendigen Änderungen für Datenbankanbieter führt, obwohl diese weitaus weniger gravierend sein sollten als die für 3.0 erforderlichen Änderungen.
Gefilterte Include-Funktion
Leitender Entwickler: @maumar
Nachverfolgbar über #1833
T-Shirt-Größe: M
Status: Fertig
Gefilterte Include-Abfragen wurden sehr oft gewünscht (ca. 376 Stimmen, 2. Platz insgesamt). Sie bedürfen nicht viel Arbeit und ermöglichen bzw. vereinfachen viele Szenarios, für die bisher Filter auf Modellebene oder komplexere Abfragen nötig sind.
Aufgeteilte Include-Abfragen
Hauptentwickler: @smitpatel
Nachverfolgbar über #20892
T-Shirt-Größe: L
Status: Fertig
EF Core 3.0 hat das Standardverhalten geändert, um eine einzelne SQL-Abfrage für eine bestimmte LINQ-Abfrage zu erstellen. Dies führte zu großen Leistungsregressionen für Abfragen, die Include für mehrere Auflistungen verwenden.
In EF Core 5.0 behalten wir das neue Standardverhalten bei. EF Core 5.0 lässt jedoch jetzt die Generierung mehrerer Include-Abfragen für Sammlungen zu, bei denen eine einzelne Abfrage zu Leistungsproblemen führen würde.
Erforderliche Elemente mit 1:1-Abhängigkeit
Leitende Entwickler: @AndriySvyryd und @smitpatel
Nachverfolgbar über #12100
T-Shirt-Größe: M
Status: Fertig
In EF Core 3.0 sind alle abhängigen Elemente optional, einschließlich nicht eigenständiger Typen (Person.Address kann beispielsweise NULL sein). In EF Core 5.0 können Abhängige nach Bedarf konfiguriert werden.
Rationalisieren von ToTable, ToQuery, ToView, FromSql usw.
Leitende Entwickler: @AndriySvyryd und @smitpatel
Nachverfolgbar über #17270
T-Shirt-Größe: L
Status: Fertig
Wir haben in früheren Versionen Fortschritte bei der Unterstützung von rohen SQL-, schlüssellosen Typen und verwandten Bereichen erzielt. Es gibt jedoch sowohl Lücken als auch Inkonsistenzen in der Art und Weise, wie alles als Ganzes zusammen funktioniert. Ziel von 5.0 ist es, diese zu beheben und eine gute Erfahrung für das Definieren, Migrieren und Verwenden verschiedener Entitätstypen und der zugehörigen Abfragen und Datenbankartefakte zu schaffen. Dies kann auch Aktualisierungen der kompilierten Abfrage-API umfassen.
Dadurch kann es jedoch zu Breaking Changes auf Anwendungsebene kommen, da manche der aktuell verfügbaren Funktionen den Benutzern zu viel ermöglichen und dadurch Fehler provoziert werden. Wir werden wahrscheinlich einige dieser Funktionen zusammen mit Anleitungen dazu blockieren, was stattdessen zu tun ist.
Allgemeine Abfrageverbesserungen
Leitende Entwickler: @smitpatel und @maumar
Nachverfolgbar über Liste der Probleme im 5.0-Meilenstein mit der Bezeichnung area-query
T-Shirt-Größe: XL
Status: Fertig
Der Abfrageübersetzungscode wurde für EF Core 3.0 umfassend neu geschrieben. Der Abfragecode befindet sich in der Regel in einem wesentlich robusteren Zustand. Für 5.0 planen wir nicht, wichtige Abfrageänderungen vorzunehmen, außerhalb derjenigen, die erforderlich sind, um TPT zu unterstützen und Navigationseigenschaften zu überspringen. Es ist jedoch noch erhebliche Arbeit erforderlich, um einige technische Schulden aus der Überholung von 3.0 zu beheben. Außerdem planen wir, viele Fehler zu beheben und kleine Verbesserungen zu implementieren, um die gesamte Abfrageerfahrung weiter zu verbessern.
Migrations- und Bereitstellungserfahrung
Leitende Entwickler: @bricelam
Nachverfolgbar über #19587
T-Shirt-Größe: L
Status: Bereichsbezogen/Erledigt
Bereichsdefinition: Das Migrationsbundlefeature wurde bis auf einen Zeitpunkt nach dem EF Core 5.0-Release verschoben. Einige andere Verbesserungen für Migrationen sind jedoch im EF Core 5.0-Release enthalten.
Derzeit migrieren viele Entwickler ihre Datenbanken zum Start der Anwendung. Dies ist einfach, wird aber nicht empfohlen, da:
- Mehrere Threads/Prozesse/Server können versuchen, die Datenbank gleichzeitig zu migrieren.
- Anwendungen versuchen möglicherweise, auf den inkonsistenten Zustand zuzugreifen, während dies geschieht
- In der Regel sollten die Datenbankberechtigungen zum Ändern des Schemas nicht für die Anwendungsausführung erteilt werden.
- Es ist schwierig, auf einen sauberen Zustand zurückzusetzen, wenn etwas schief geht.
Wir möchten hier eine bessere Erfahrung bieten, die eine einfache Möglichkeit zum Migrieren der Datenbank während der Bereitstellung schafft. Dies sollte folgendes sein:
- Arbeiten mit Linux, Mac und Windows
- Unkompliziert über die Befehlszeile ausführbar
- Unterstützung von Szenarien mit Containern
- Kombinierbar mit häufig verwendeten Bereitstellungstools/-flows
- Integrieren in mindestens Visual Studio
Das Ergebnis ist wahrscheinlich viele kleine Verbesserungen in EF Core (z. B. bessere Migrationen auf SQLite), zusammen mit Anleitungen und längerfristigen Zusammenarbeiten mit anderen Teams, um End-to-End-Erfahrungen zu verbessern, die über nur EF hinausgehen.
EF Core-Plattformerfahrung
Leitende Entwickler: @roji und @bricelam
Nachverfolgbar über #19588
T-Shirt-Größe: L
Status: Bereich/Erledigt
Bereich: Plattformanleitungen und Beispiele werden für Blazor, Xamarin, WinForms und WPF veröffentlicht. Xamarin- sowie weitere AOT-/Linker-Verbesserungen sind für EF Core 6.0 geplant.
Wichtig
Xamarin.Android, Xamarin.iOS, Xamarin.Mac sind jetzt direkt in .NET (beginnend mit .NET 6) als .NET für Android, .NET für iOS und .NET für macOS integriert. Wenn Sie noch heute mit diesen Projekttypen erstellen, sollten sie auf .NET SDK-Stilprojekte aktualisiert werden, um weiterhin Unterstützung zu erhalten. Weitere Informationen zum Upgrade von Xamarin-Projekten auf .NET finden Sie in der Dokumentation Upgrade von Xamarin auf .NET & .NET MAUI.
Wir haben gute Anleitungen für die Verwendung von EF Core in herkömmlichen MVC-ähnlichen Webanwendungen. Anleitungen für andere Plattformen und Anwendungsmodelle fehlen oder sind veraltet. Für EF Core 5.0 planen wir die Untersuchung, Verbesserung und Dokumentation der Verwendung von EF Core mit:
- Blazor
- Xamarin, einschließlich der Verwendung von AOT/Linker-Story
- WinForms/WPF/WinUI und möglicherweise andere U.I.-Frameworks
Dies werden wahrscheinlich viele kleine Verbesserungen in EF Core sein, gemeinsam mit Anleitungen und längerfristiger Zusammenarbeit mit anderen Teams, um End-to-End-Prozesse zu verbessern, die über EF hinausgehen.
Bestimmte Bereiche, die wir betrachten möchten, sind:
- Bereitstellung, einschließlich der Verwendung von EF-Tools, z. B. für Migrationen
- Anwendungsmodelle, einschließlich Xamarin und Blazor, und wahrscheinlich andere
- SQLite-Erfahrungen, einschließlich der räumlichen Erfahrung und Tabellenneuerstellung
- AOT und Verknüpfen von Erfahrungen
- Integration von Diagnosefunktionen, einschließlich Leistungsindikatoren
Leistung
Leitender Entwickler: @roji
Nachverfolgbar über Liste der Probleme im 5.0-Meilenstein mit der Bezeichnung area-perf
T-Shirt-Größe: L
Status: Erfasst/Fertig
Bereichsdefinition: Wichtige Leistungsverbesserungen beim Npgsql-Anbieter wurden abgeschlossen. Weitere Leistungsverbesserungen sind für EF Core 6.0 geplant.
Für EF Core planen wir, unsere Suite von Leistungs-Benchmarks zu verbessern und gerichtete Leistungsverbesserungen an der Laufzeit vorzunehmen. Darüber hinaus planen wir, die neue ADO.NET Batchverarbeitungs-API abzuschließen, die während des 3.0-Releasezyklus prototypiert wurde. Auch auf der ADO.NET-Ebene planen wir zusätzliche Leistungsverbesserungen für den Npgsql-Anbieter.
Im Rahmen dieser Arbeit planen wir auch, ADO.NET/EF Core-Leistungsindikatoren und andere Diagnosen entsprechend hinzuzufügen.
Dokumentation zu Architektur/Mitwirkenden
Hauptdokumentator: @ajcvickers
Nachverfolgbar über #1920
T-Shirt-Größe: L
Status: Ausschneiden
Die Idee hier ist es, das Verständnis dessen zu erleichtern, was im Inneren von EF Core vor sich geht. Dies kann für jeden nützlich sein, der EF Core verwendet, aber die primäre Motivation besteht darin, es externen Personen einfacher zu machen:
- Mitwirken am EF Core-Code
- Datenbankanbieter erstellen
- Erstellen weiterer Erweiterungen
Update: Leider war dieser Plan zu ehrgeizig. Wir glauben immer noch, dass dies wichtig ist, aber leider wird es nicht mit EF Core 5.0 landen.
Microsoft.Data.Sqlite-Dokumentation
Hauptdokumentierer: @bricelam
Nachverfolgbar über #1675
T-Shirt-Größe: M
Status: Abgeschlossen. Die neue Dokumentation finden Sie auf Microsoft Learn.
Das EF-Team besitzt auch den Microsoft.Data.Sqlite ADO.NET Anbieter. Wir planen, diesen Anbieter im Rahmen der Version 5.0 vollständig zu dokumentieren.
Allgemeine Dokumentation
Für die Dokumentation verantwortliche Person: @ajcvickers
Nachverfolgbar über Probleme in Dokumentation-Repository im 5.0-Meilenstein
T-Shirt-Größe: L
Status: In Bearbeitung
Wir sind bereits dabei, die Dokumentation für die Versionen 3.0 und 3.1 zu aktualisieren. Wir arbeiten auch an:
- Überarbeitung der Einsteigerartikel, um sie ansprechender und leichter verständlich zu machen
- Reorganisation von Artikeln, um das Auffinden und Hinzufügen von Querverweisen zu erleichtern
- Hinzufügen weiterer Details und Klarstellungen zu vorhandenen Artikeln
- Aktualisieren der Beispiele und Hinzufügen weiterer Beispiele
Beheben von Fehlern
Nachverfolgbar über Liste der Probleme im 5.0-Meilenstein mit der Bezeichnung type-bug
Entwickler: @roji, @maumar, @bricelam, @smitpatel, @AndriySvyryd @ajcvickers
T-Shirt-Größe: L
Status: In Bearbeitung
Zum Zeitpunkt des Schreibens haben wir 135 Fehler, die in der Version 5.0 behoben werden sollen, von denen 62 bereits behoben wurden. Es gibt jedoch erhebliche Überschneidungen mit dem obenstehenden Abschnitt Allgemeine Abfrageverbesserungen.
Im Laufe des Releases 3.0 wurden pro Monat etwa 23 Issues in Meilensteine aufgenommen. Nicht alle diese müssen in 5.0 behoben werden. Als grobe Schätzung planen wir, eine zusätzliche 150 Probleme im Zeitrahmen von 5,0 zu beheben.
Kleine Verbesserungen
Nachverfolgbar über Liste der Probleme im 5.0-Meilenstein mit der Bezeichnung type-enhancement
Entwickler: @roji, @maumar, @bricelam, @smitpatel, @AndriySvyryd @ajcvickers
T-Shirt-Größe: L
Status: Fertig
Zusätzlich zu den oben beschriebenen größeren Features sind in Version 5.0 auch viele kleinere Verbesserungen geplant, mit denen Probleme behoben werden, die als unkritisch gelten. Beachten Sie, dass viele dieser Verbesserungen auch von den oben beschriebenen allgemeineren Themen abgedeckt werden.
Verschoben auf nächste Version
Nachverfolgbar über Liste der Probleme im 5.0-Meilenstein mit der Bezeichnung consider-for-next-release
Dabei handelt es sich um Fehlerbehebungen und Verbesserungen, die aktuell nicht für das Release 5.0 vorgesehen sind, aber je nach Fortschritt bei den oben beschriebenen Zielen zusätzlich angegangen werden.
Darüber hinaus berücksichtigen wir bei der Planung immer die am meisten abgestimmten Themen. Das Abschneiden eines dieser Probleme aus einer Veröffentlichung ist immer schmerzhaft, aber wir brauchen einen realistischen Plan für die ressourcen, die wir haben.
Anregungen
Ihr Feedback zur Planung ist wichtig. Die beste Möglichkeit, die Wichtigkeit eines Problems anzugeben, besteht darin, für dieses Problem auf GitHub abzustimmen (Daumen nach oben). Diese Daten werden dann in den Planungsprozess für die nächste Version eingespeist.