Freigeben über

Neuerungen in EF Core 10

EF Core 10 (EF10) ist die nächste Version nach EF Core 9 und ist für die Veröffentlichung im November 2025 geplant.

EF10 ist als Vorschau verfügbar. Informationen zur neuesten Vorschau finden Sie in den Versionshinweisen für .NET 10. Dieser Artikel wird aktualisiert, wenn neue Vorschauversionen verfügbar gemacht werden.

Tipp

Sie können die Beispiele ausführen und debuggen, indem Sie den Beispielcode von GitHubherunterladen. Jeder Abschnitt unten verweist auf den Quellcode, der für diesen Abschnitt spezifisch ist.

EF10 erfordert das .NET 10 SDK zum Erstellen sowie die .NET 10-Laufzeit für die Ausführung. EF10 wird nicht in früheren .NET-Versionen ausgeführt und wird nicht unter .NET Framework ausgeführt.

Azure Cosmos DB für NoSQL-Datenbanklösungen

Unterstützung der Volltextsuche

Azure Cosmos DB bietet jetzt Unterstützung für die Volltextsuche. Sie ermöglicht effiziente und effektive Textsuchen sowie die Auswertung der Relevanz von Dokumenten für eine bestimmte Suchabfrage. Sie kann in Kombination mit der Vektorsuche verwendet werden, um die Genauigkeit von Antworten in einigen KI-Szenarien zu verbessern. EF Core 10 bietet Unterstützung für dieses Feature, das die Modellierung der Datenbank mit volltextfähigen Eigenschaften und die Verwendung von Volltext-Suchfunktionen in Abfragen für Azure Cosmos DB ermöglicht.

Hier ist eine grundlegende EF-Modellkonfiguration, die die Volltextsuche für eine der Eigenschaften ermöglicht:

public class Blog
{
    ...

    public string Contents { get; set; }
}

public class BloggingContext
{
    ...

    protected override void OnModelCreating(ModelBuilder modelBuilder)
    {
        modelBuilder.Entity<Blog>(b =>
        {
            b.Property(x => x.Contents).EnableFullTextSearch();
            b.HasIndex(x => x.Contents).IsFullTextIndex();
        });
    }
}

Nachdem das Modell konfiguriert wurde, können wir mithilfe der in EF.Functions bereitgestellten Methoden Volltext-Suchvorgänge in Abfragen verwenden.

var cosmosBlogs = await context.Blogs.Where(x => EF.Functions.FullTextContains(x.Contents, "cosmos")).ToListAsync();

Die folgenden Volltextvorgänge werden derzeit unterstützt: FullTextContains, FullTextContainsAll, FullTextContainsAny, FullTextScore.

Weitere Informationen zur Volltextsuche von Cosmos finden Sie in den Dokumenten.

EF Core unterstützt RRF jetzt die Funktion "Reziproziale Rangfusion", die die Vektorgleichheitssuche und die Volltextsuche (d. h. hybride Suche) kombiniert. Hier ist eine Beispielabfrage mithilfe der Hybridsuche:

float[] myVector = /* generate vector data from text, image, etc. */
var hybrid = await context.Blogs.OrderBy(x => EF.Functions.Rrf(
        EF.Functions.FullTextScore(x.Contents, "database"), 
        EF.Functions.VectorDistance(x.Vector, myVector)))
    .Take(10)
    .ToListAsync();

Weitere Informationen zur Cosmos-Hybridsuche finden Sie in den Dokumenten.

Vektorähnlichkeitssuche wird aus der Vorschauversion entfernt

In EF9 haben wir experimentelle Unterstützung für die Vektorähnlichkeitssuche hinzugefügt. In EF Core 10 ist die Unterstützung der Vektorähnlichkeitssuche nicht mehr experimentell. Wir haben auch einige Verbesserungen an der Funktion vorgenommen:

  • EF Core kann jetzt Container mit Vektoreigenschaften generieren, die in eigenen Referenzentitäten definiert sind. Container mit Vektoreigenschaften, die in den eigenen Sammlungen definiert sind, müssen auf eine andere Weise erstellt werden. Sie können jedoch in Abfragen verwendet werden.
  • Modellerstellungs-APIs wurden umbenannt. Eine Vektoreigenschaft kann jetzt mithilfe der IsVectorProperty Methode konfiguriert werden, und der Vektorindex kann mithilfe der IsVectorIndex Methode konfiguriert werden.

Weitere Informationen zur Cosmos-Vektorsuche finden Sie in den Dokumenten.

Verbesserte Erfahrung beim Entwickeln des Modells

In früheren Versionen von EF Core war die Entwicklung des Modells bei der Verwendung von Azure Cosmos DB ziemlich schmerzhaft. Insbesondere kann EF beim Hinzufügen einer neuen erforderlichen Eigenschaft zur Entität nicht mehr in der Lage sein, diese Entität zu materialisieren. Der Grund dafür war, dass EF einen Wert für die neue Eigenschaft erwartet hat (da sie erforderlich war), aber das Dokument, das vor der Änderung erstellt wurde, enthielt diese Werte nicht. Die Problemumgehung bestand darin, die Eigenschaft zuerst als optional zu markieren, Standardwerte für die Eigenschaft manuell hinzuzufügen und sie dann nur in erforderlich zu ändern.

In EF 10 haben wir diese Erfahrung verbessert – EF materialisiert nun einen Standardwert für eine erforderliche Eigenschaft, wenn keine Daten für sie im Dokument vorhanden sind, anstatt sie zu auslösen.

LINQ- und SQL-Übersetzung

Unterstützung für die .NET 10-LeftJoin- und RightJoin-Operatoren

LEFT JOIN ist ein gängiger und nützlicher Vorgang beim Arbeiten mit EF Core. In früheren Versionen war die Implementierung von LEFT JOIN in LINQ ziemlich kompliziert und erforderte SelectMany-, GroupJoin- und DefaultIfEmpty-Vorgänge in einer bestimmten Konfiguration.

.NET 10 fügt erstklassige LINQ-Unterstützung für LeftJoin Methode hinzu, wodurch diese Abfragen wesentlich einfacher zu schreiben sind. EF Core erkennt die neue Methode, sodass sie in EF LINQ-Abfragen anstelle des alten Konstrukts verwendet werden kann:

var query = context.Students
    .LeftJoin(
        context.Departments,
        student => student.DepartmentID,
        department => department.ID,
        (student, department) => new 
        { 
            student.FirstName,
            student.LastName,
            Department = department.Name ?? "[NONE]"
        });

Hinweis

EF 10 unterstützt auch den analogen RightJoin Operator, der alle Daten aus der zweiten Sammlung und nur die übereinstimmenden Daten aus der ersten Sammlung speichert. EF 10 übersetzt dies in den RIGHT JOIN-Vorgang in der Datenbank.

Weitere Informationen finden Sie unter Nr. 12793 und #35367.

Weitere Abfrageverbesserungen

  • Translate DateOnly.ToDateTime(timeOnly) (#35194, von @mseada94 beigetragen).
  • Optimieren Sie mehrere aufeinander folgende LIMITs (#35384, von @ranma42 beigetragen).
  • Optimieren Sie den Einsatz der Count-Funktion auf ICollection<T> (#35381, beigetragen von @ChrisJollyAU).
  • Optimieren MIN/MAX über DISTINCT (#34699, von @ranma42 beigetragen).
  • Übersetzen Von Datums-/Uhrzeitfunktionen mithilfe der Argumente DatePart.Microsecond und DatePart.Nanosecond (#34861).
  • Vereinfachen Sie Parameternamen (z. B. von @__city_0 bis city) (#35200).
  • Übersetzen Sie COALESCE in den meisten Fällen wie ISNULL in SQL Server (#34171, von @ranma42 beigetragen).
  • Die Unterstützung einiger Zeichenfolgenfunktionen, die char als Argumente verwenden, wurde eingeführt (#34999, von @ChrisJollyAU beigetragen).
  • Unterstützung MAX/MIN/ORDER BY mit decimal auf SQLite (#35606, beigetragen von @ranma42).
  • Unterstützung der Projektion verschiedener Navigationen (aber gleichen Typs) über einen bedingten Operator (#34589, beigetragen von @ranma42).

ExecuteUpdateAsync akzeptiert jetzt eine normale Lambda-Funktion ohne Ausdruck

Die ExecuteUpdateAsync kann verwendet werden, um beliebige Aktualisierungsvorgänge in der Datenbank auszudrücken. In früheren Versionen wurden die Änderungen, die für die Datenbankzeilen ausgeführt werden sollen, über einen Ausdrucksstrukturparameter bereitgestellt; Dies hat es recht schwierig gemacht, diese Änderungen dynamisch zu erstellen. Angenommen, Sie möchten die Ansichten eines Blogs aktualisieren, aber bedingt auch dessen Namen. Da das Setter-Argument ein Ausdrucksbaum war, musste folgender Code geschrieben werden:

// Base setters - update the Views only
Expression<Func<SetPropertyCalls<Blog>, SetPropertyCalls<Blog>>> setters =
    s => s.SetProperty(b => b.Views, 8);

// Conditionally add SetProperty(b => b.Name, "foo") to setters, based on the value of nameChanged
if (nameChanged)
{
    var blogParameter = Expression.Parameter(typeof(Blog), "b");

    setters = Expression.Lambda<Func<SetPropertyCalls<Blog>, SetPropertyCalls<Blog>>>(
        Expression.Call(
            instance: setters.Body,
            methodName: nameof(SetPropertyCalls<Blog>.SetProperty),
            typeArguments: [typeof(string)],
            arguments:
            [
                Expression.Lambda<Func<Blog, string>>(Expression.Property(blogParameter, nameof(Blog.Name)), blogParameter),
                Expression.Constant("foo")
            ]),
        setters.Parameters);
}

await context.Blogs.ExecuteUpdateAsync(setters);

Das manuelle Erstellen von Ausdrucksbäumen ist kompliziert und fehleranfällig, wodurch dieses häufige Szenario viel schwieriger wurde, als es sein sollte. Ab EF 10 können Sie stattdessen Folgendes schreiben:

await context.Blogs.ExecuteUpdateAsync(s =>
{
    s.SetProperty(b => b.Views, 8);
    if (nameChanged)
    {
        s.SetProperty(b => b.Name, "foo");
    }
});

Dank @aradalvand für das Vorschlagen und Durchsetzen dieser Änderung (in #32018).

Benutzerdefinierte Standardeinschränkungsnamen

Wenn Sie in früheren Versionen von EF Core einen Standardwert für eine Eigenschaft angegeben haben, würde EF Core immer zulassen, dass die Datenbank automatisch einen Einschränkungsnamen generiert. Jetzt können Sie explizit den Namen für Standardwertseinschränkungen für SQL Server angeben, sodass Sie ihr Datenbankschema besser steuern können.

Sie können nun beim Definieren von Standardwerten in der Modellkonfiguration einen Einschränkungsnamen angeben:

protected override void OnModelCreating(ModelBuilder modelBuilder)
{
    modelBuilder.Entity<Blog>()
        .Property(b => b.IsActive)
        .HasDefaultValue(true, "DF_Blog_IsActive");

    modelBuilder.Entity<Post>()
        .Property(p => b.CreatedDate)
        .HasDefaultValueSql("GETDATE()", "DF_Post_CreatedDate");
}

Sie können auch aufrufen UseNamedDefaultConstraints , um die automatische Benennung aller Standardeinschränkungen zu aktivieren. Beachten Sie, dass bei vorhandenen Migrationen die nächste hinzugefügte Migration jede einzelne Standardeinschränkung in Ihrem Modell umbenennen wird.

protected override void OnModelCreating(ModelBuilder modelBuilder)
{
    modelBuilder.UseNamedDefaultConstraints();
}

Weitere Verbesserungen

  • Sql Server-Gerüst mit Azure Data Explorer kompatibel machen (#34832, von @barnuri).
  • Zuordnen von DatabaseRoot zur Instanz mit den bereichsbezogenen Optionen und nicht den Singletonoptionen (#34477, beigetragen von @koenigst).
  • Zeichenkettenkonstanten aus dem Protokoll entfernen, wenn die sensible Protokollierung deaktiviert ist (#35724).
  • Verbessern Sie LoadExtension so, dass sie korrekt mit dotnet run und libs mit dem Namen lib* funktioniert (#35617, beigetragen von @krwq).
  • Änderungen an der AsyncLocal-Verwendung für eine bessere Lazy Loading-Leistung (#35835, beigetragen von @henriquewr).