So ordnen Sie DateOnly- und TimeOnly-Typen SQL zu (2023)

In diesem Beitrag erfahren Sie, wie Sie die Typen „DateOnly“ und „TimeOnly“ durch Migration SQL zuordnen.

Um den Quellcode für diesen Artikel herunterzuladen, können Sie unsere besuchenGitHub-Repository.

Lass uns eintauchen.

DateOnly- und TimeOnly-Typen in .NET

Vor .NET 6 hatten wir hauptsächlichTerminzeitUndDateTimeOffsetStrukturtypen zur Handhabung von Datum und Uhrzeit. Wie der Name schon sagt, stellen solche Datentypen konvergierte Datums- und Uhrzeitwerte dar.In vielen Szenarien möchten wir uns jedoch nur mit Datumsangaben befassen, ohne uns überhaupt um die Zeit zu kümmern, und umgekehrt.

Wenn wir zum Beispiel über den Geburtstag einer Person sprechen, kümmern wir uns ganz bestimmt nicht um die Tageszeit. Gleiches gilt für die Arbeitszeiten eines Mitarbeiters – es ist sinnlos, solche Daten mit einem Datumsteil darzustellen, da ein bestimmtes Datum irrelevant wäre.

Eine mögliche Problemumgehung für solche Fälle könnte seinAbschneiden des Zeitteilsoder Datumsteil vonTerminzeitoderDateTimeOffsetWerte. Auch in diesem Fall benötigen wir eine Sonderbehandlung, um sicherzustellen, dass der Wert des verbleibenden Teils unberührt bleibt. Selbst dann könnten wir fehlerhafte Ergebnisse erhalten, weilDateTime/DateTimeOffsetenthält auch Zeitzoneninformationen und ist nicht für die Verarbeitung absoluter Datums- und Uhrzeitangaben ausgelegt.

Letztendlich ähneln solche Problemumgehungen der Verwendung vondoppeltDatentyp, der gehalten werden sollganze ZahlWerte. Darüber hinaus bedeuten diese Typen die gemeinsame Verwendung von Datums- und Zeitkomponenten, und ihre Verwendung nur mit Teilwerten kann irreführend sein.

.NET 6 geht dieses Problem durch die Einführung anNur DatumUndTimeOnlyStrukturen. Dadurch können wir unsere Datenmodelle genau so gestalten, wie wir es wollen:

öffentliche Klasse Employee{ public int Id { get; Satz; } öffentlicher String Name { get; Satz; } = null!; public DateOnly BirthDate { get; Satz; } public TimeOnly WorkStartTime { get; Satz; } public TimeOnly WorkEndTime { get; Satz; }}

In diesemMitarbeiterModell, die Datentypen vonGeburtsdatum,WorkStartTime, UndWorkEndTimestehen eindeutig im Einklang mit ihrem Zweck.

Der SQLite-Datenanbieter (Microsoft.Data.Sqlite 6.0) unterstützt diese neuen Typen auch standardmäßig. Dadurch können wir solche Entitätsmodelle nahtlos in EF Core mit SQLite-Adaptern verwenden.

Ordnen Sie DateOnly- und TimeOnly-Typen mit SQL Server zu

Leider funktioniert EF Core 7 (und frühere Versionen) mit dem SQL Server-Anbieter nicht gut mit diesen neuen Typen.

Um das Problem aus erster Hand zu sehen, bereiten wir einen Datenbankkontext vor, einschließlich unseresMitarbeiterEntitätssatz:

öffentliche Klasse AppDbContext: DbContext{ public DbSet Employees => Set(); protected override void OnConfiguring(DbContextOptionsBuilder builder) { if (builder.IsConfigured) return; var Configuration = new ConfigurationBuilder() .AddJsonFile("appsettings.json") .Build(); builder.UseSqlServer(configuration.GetConnectionString("Default")); }}

Dies ist ein typischer Code-First-Ansatz von EF Core zum Einrichten einesDbContext. Im InnerenOnConfiguring()Methode konfigurieren wir den SQL Server-Datenbankanbieter mit der gewünschtenConnectionString.

Jetzt versuchen wir, mithilfe der Package Manager Console ein Gerüst für die anfängliche Migrationsdatei zu erstellen, etwa so:

PM> Add-Migration Initial_Create

Aber wir stoßen auf eine Ausnahme:

System.InvalidOperationException: Die Eigenschaft „Employee.BirthDate“ konnte nicht zugeordnet werden, da sie vom Typ „DateOnly“ ist, der kein unterstützter primitiver Typ oder gültiger Entitätstyp ist. Ordnen Sie diese Eigenschaft entweder explizit zu oder ignorieren Sie sie mithilfe des Attributs „[NotMapped]“ oder mithilfe von „EntityTypeBuilder.Ignore“ in „OnModelCreating“.

Offensichtlich unterstützt EF Core 7 die Zuordnung von nichtNur DatumUndTimeOnlyTypen direkt in SQL Server-Spalten umwandeln.

Die gute Nachricht ist, dass beide Datentypen in EF Core 8 unterstützt werden.

Aber gibt es eine Möglichkeit, mit EF Core 7 eine funktionierende Lösung zu erreichen? Ja da ist!

EF Core 7-Unterstützung mit Wertekonverter

Unsere Lösung knüpft an eine der großartigen Funktionen von EF Core an – die Unterstützung für das Einbinden eines benutzerdefinierten Wertekonverters, der die Konvertierung von/in gespeicherte Werte übernimmt. Das heißt, wenn wir Wertobjekte nicht unterstützter Datentypen in solche unterstützter Datentypen konvertieren können, können wir unser Problem lösen. In unserem Fall,TerminzeitUndZeitspannesind die unterstützten Standardgegenstücke vonNur DatumUndTimeOnlyTypen bzw.

Lassen Sie uns zunächst den Konverter für implementierenNur Datum:

öffentliche Klasse DateOnlyConverter: ValueConverter{ public DateOnlyConverter(): base( dateOnly => dateOnly.ToDateTime(TimeOnly.MinValue), dateTime => DateOnly.FromDateTime(dateTime)) { }}

Wir erweitern einfach das GenerikumValueConverter<>und liefern die notwendigen Konvertierungsfunktionen als Konstruktorargumente. DerNur Datumstruct wird mit einigen geliefertAus*/Zu*Routinen, die für solche Hin- und Herkonvertierungen nützlich sind.

Als nächstes benötigen wir den Konverter fürTimeOnly:

öffentliche Klasse TimeOnlyConverter: ValueConverter{ public TimeOnlyConverter(): base( timeOnly => timeOnly.ToTimeSpan(), timeSpan => TimeOnly.FromTimeSpan(timeSpan)) { }}

Ähnlich zuNur Datum,TimeOnlystellt außerdem die notwendigen Routinen zur Umsetzung der Konvertierung von/nach bereitZeitspanne.

Registrieren Sie benutzerdefinierte Konverter

Es ist Zeit, unsere benutzerdefinierten Konverter beim Kontextmodell-Builder zu registrieren:

öffentliche Klasse AppDbContext: DbContext{ // der Kürze halber weggelassen protected override voidConfigureConventions(ModelConfigurationBuilder builder) { base.ConfigureConventions(builder); builder.Properties() .HaveConversion(); builder.Properties() .HaveConversion(); }}

Durch Überschreiben desKonfigurierenConventions()Methode erhalten wir Zugriff auf den Konfigurations-Builder. Anschließend registrieren wir unsDateOnlyConverterfür alleNur DatumEigenschaften mithilfe derHaveConversion()Konfigurator-Methode. Ebenso registrieren wir unsTimeOnlyConverterfür alleTimeOnlyEigenschaften.

Jetzt können wir ein Gerüst für die Migrationsdatei erstellen:

öffentliche Teilklasse InitialCreate : Migration{ protected override void Up(MigrationBuilder migrationBuilder) { migrationBuilder.CreateTable( name: "Employees", columns: table => new { Id = table.Column(type: "int", nullable: false) .Annotation("SqlServer:Identity", "1, 1"), Name = table.Column(type: "nvarchar(max)", nullable: false), BirthDate = table.Column( Typ: „datetime2“, nullable: false), WorkStartTime = table.Column(type: „time“, nullable: false), WorkEndTime = table.Column(type: „time“, nullable: false) }, Einschränkungen: table => { table.PrimaryKey("PK_Employees", x => x.Id); }); }}

Schön, wir haben erfolgreich kartiertDateOnly/TimeOnlyEigenschaften in unsere Datenbankspalten ein. Aber wir sind noch nicht fertig.

Ordnen Sie DateOnly und TimeOnly den richtigen SQL-Typen zu

Aus der Gerüstmigrationsdatei sehen wirTimeOnlyEigenschaften werden korrekt ihrem richtigen SQL-Äquivalent von „ zugeordnetZeit„. AberNur DatumEigenschaften werden als „DatumUhrzeit2” was ein Äquivalent von istTerminzeit. Das ist nicht das, was wir wollen. Stattdessen möchten wir es als „Datum„:

protected override voidConfigureConventions(ModelConfigurationBuilder builder){ base.ConfigureConventions(builder); builder.Properties() .HaveConversion() .HaveColumnType("date"); builder.Properties() .HaveConversion();}

Noch einmal konfigurieren wir dies innerhalb derKonfigurierenConventions()Methode. Ein verkettender Anruf anHaveColumnType("Datum")aus dem vorherigen Konfigurator vonNur Datummacht den Job!

Während wir die Migrationsdatei neu aufbauen:

protected override void Up(MigrationBuilder migrationBuilder){ migrationBuilder.CreateTable( name: „Employees“, columns: table => new { Id = table.Column(type: „int“, nullable: false) .Annotation(“SqlServer :Identity", "1, 1"), Name = table.Column(type: "nvarchar(max)", nullable: false), BirthDate = table.Column(type: "date", nullable : false), WorkStartTime = table.Column(type: "time", nullable: false), WorkEndTime = table.Column(type: "time", nullable: false) }, Einschränkungen: table => { table.PrimaryKey("PK_Employees", x => x.Id); });}

Und dieses Mal finden wirGeburtsdatumkorrekt als Spalte „Datum“ zugeordnet.

Registrieren Sie den benutzerdefinierten Vergleicher

Unsere CLR-zu-SQL-Datenzuordnung ist in gutem Zustand. Wir haben jedoch immer noch ein Problem mit dem zugrunde liegenden Änderungsverfolgungsmechanismus von EF Core. In unserem benutzerdefinierten Konverter transformieren wir eine Struktur (Nur Datum) mit ein paar Eigenschaften zu einer Struktur (Terminzeit) mit einer höheren Anzahl von Eigenschaften. Dies bedeutet Redundanz beim generischen Vergleich zwischen den nicht verwendeten Eigenschaften, was tatsächlich zusätzlichen Aufwand für den Änderungsverfolgungsworkflow von EF verursacht.

Wir können diesen Mehraufwand vermeiden, indem wir kostenlose Vergleichswerte bereitstellen:

öffentliche Klasse DateOnlyComparer: ValueComparer{ public DateOnlyComparer(): base( (x, y) => x.DayNumber == y.DayNumber, dateOnly => dateOnly.GetHashCode()) { }}

Wir haben zunächst einen Wertvergleich für entwickeltNur Datum. Ein solcher Vergleicher erwartet natürlich ein Vergleichsprädikat. In unserem Fall ist es einfach genug, das zu vergleichenTagesnummerEigentum von zweiNur DatumWerte. Wir verbessern es weiter, indem wir eine Hash-Provider-Funktion bereitstellen, die einfach den Hash-Code von weiterleitetNur DatumBeispiel.

Ebenso können wir einen Vergleicher für implementierenTimeOnlydurch die Verwendung derZeckenEigentum:

öffentliche Klasse TimeOnlyComparer: ValueComparer{ public TimeOnlyComparer(): base( (x, y) => x.Ticks == y.Ticks, timeOnly => timeOnly.GetHashCode()) { }}

Lassen Sie uns unsere ändernAppDbContextKlasse, um diese Vergleicher mit unseren benutzerdefinierten Konvertern zu verknüpfen:

protected override voidConfigureConventions(ModelConfigurationBuilder builder){ base.ConfigureConventions(builder); builder.Properties() .HaveConversion() .HaveColumnType("date"); builder.Properties() .HaveConversion();}

Wir müssen lediglich den Vergleicher zusammen mit der Konverterregistrierung angeben.

Testen von DbContext mit DateOnly- und TimeOnly-Werten

UnserAppDbContextist jetzt korrekt für die Verarbeitung konfiguriertNur DatumUndTimeOnlyWerte.

Wir fügen einen Beispiel-Mitarbeitereintrag ein:

var Employee = neuer Mitarbeiter{ Name = „John Doe“, BirthDate = new DateOnly(2023, 5, 9), WorkStartTime = new TimeOnly(8, 30), WorkEndTime = new TimeOnly(4, 30)};_context.Employees. Add(employee);_context.SaveChanges();

Und dann den gespeicherten Datensatz in der Datenbank durchsuchen:

Wir können sehen, dass dieGeburtsdatumSpalte hat keinen redundanten Zeitteil undWorkStartTime/WorkEndTimeSpalten haben keinen redundanten Datumsteil.

Auswirkungen auf die Leistung von DateOnly- und TimeOnly-Konvertierungen

Wenn wir einen benutzerdefinierten Wertkonverter verwenden, muss EF Core den Konverter aufrufen, um den Eigenschaftswert beim Schreiben in die Datenbank in die entsprechende Datenbankdarstellung zu konvertieren, und umgekehrt beim Lesen aus der Datenbank. Dieser zusätzliche Konvertierungsschritt kann zu einem gewissen Mehraufwand führen und möglicherweise die Leistung beeinträchtigen. Solche Konverter erfordern jedoch in der Regel keine rechenintensiven Vorgänge und haben daher im Allgemeinen vernachlässigbare Auswirkungen.

UnserDateOnlyConverterbasiert auf zwei integrierten Funktionen –DateOnly.FromDateTime()UndToDateTime(). DerDateOnly.FromDateTime()Methode ist optimiert, um eine zu erstellenNur DatumWert von aTerminzeitindem nur der Datumsteil extrahiert und der Zeitteil ignoriert wird. Andererseits,ToDateTime()weist dem eine bestimmte Zeit (z. B. Mitternacht) zuNur DatumWert, um einen zu erstellenTerminzeitDarstellung.

Solche Vorgänge sind ziemlich einfach und unkompliziert. Gleiches gilt fürTimeOnlyConverter. Das bedeutet, dass die Auswirkungen minimal sein sollten und wahrscheinlich keinen Leistungsengpass darstellen, es sei denn, wir haben es mit einer außergewöhnlich großen Anzahl von Konvertierungen zu tun oder führen sie in einem Szenario mit hohem Durchsatz durch.

Im Allgemeinen empfiehlt es sich jedoch, Leistungsprofile zu verwenden, wenn wir benutzerdefinierte Wertkonverter verwenden.

Abschluss

In diesem Artikel haben wir gelernt, wie man mithilfe von EF Core 7 DateOnly- und TimeOnly-Typen einer SQL Server-Datenbank zuordnet. Obwohl EF Core 7 eine solche Zuordnung nicht standardmäßig unterstützt, können wir dies mit ein paar Anpassungen tun. Zum Glück können wir dies tun. Unterstützung für diese Datentypen innerhalb des SQL Server-Anbieters ist ab EF Core 8 verfügbar.