Beginners Guide – API-Entwicklung in der Microsoft-Welt (Teil 3): Entity Framework Migration

Hier die ersten zwei Teile meines Beginner Guides:

• API-Entwicklung in der Microsoft-Welt (Teil 1): Architektur und Infrastruktur

• API-Entwicklung in der Microsoft-Welt (Teil 2): .Net-5.0-Projektstruktur

Die Projektstruktur ist nun festgelegt und wir können mit der Entwicklung beginnen. Damit wir später in unserer Anwendung Inhalte abrufen, speichern und modifizieren können, konzipieren wir nun das Datenbankmodell.

Damit auch alles klappt, sollten folgende NuGet-Pakete für das Projekt installiert sein:

Im folgenden Szenario möchte der Kunde verschiedenen Gaststätten eine einfache Terminbuchung über eine Weboberfläche ermöglichen. Unser Datenbankmodell könnte daher z.B. so aussehen:

Durch den Code-First-Ansatz, welcher vom Entity Framework verfolgt wird, können wir die Datenbank-Entitäten als Klassen in C# bereits anlegen. Pro Entität wird eine Klasse erstellt, so ist die Tabelle Tables folgenderweise als Code dargestellt:

using System;

namespace OKBLOGAPI.Domain.Entities
{
    public class Table
    {
        public Guid Id { get; set; }

        public Guid RestaurantId { get; set; }

        public Restaurant Restaurant { get; set; }

        public int Position { get; set; }
    }
}

Der Bezug zur Entität Restaurant wird durch einen Fremdschlüssel dargestellt. Auch hier gibt es verschiedene Möglichkeiten, Beziehungen zu definieren. Hier findet ihr dazu eine ausführliche Dokumentation.

Damit die Entitäten auch tatsächlich auf der Datenbank erzeugt werden, muss eine Migration ausgeführt werden. Im Migrationsprozess werden Stand von Code und Datenbank verglichen – die daraus resultierende Differenz wird dementsprechend danach angepasst. Im Zuge dessen muss erst einmal die Verbindung zur Datenbank definiert werden – auch als Kontext bekannt.

public class OKBLOGContext : DbContext
    {
        public DbSet<Restaurant> Restaurant { get; set; }

        public DbSet<Customer> Customer { get; set; }

        public DbSet<Table> Tables { get; set; }

        public DbSet<Booking> Bookings { get; set; }
      
		...........
     	...........
      
        protected override void OnConfiguring(DbContextOptionsBuilder optionsBuilder)
        {
            var connectionString = "Server=tcp:okblog.database.windows.net,1433;" +
                    "Initial Catalog=OKBLOG;Persist Security Info=False;" +
                    "User ID=okblogsa;Password=;" +
                    "MultipleActiveResultSets=False; Encrypt=True;" +
                    "TrustServerCertificate=False;Connection Timeout=30;";

            optionsBuilder.UseSqlServer(connectionString);
        }
    }

Durch die Properties geben wir an, welche Entitäten für den Kontext relevant sind und bei einer Migration betrachtet werden sollen. Überschreiben wir die Funktion OnConfiguring aus DbContext können wir die Verbindung zum SQL-Server als Connectionstring definieren. Hierfür benötigt man die richtigen Credentials, die wir im ersten Artikel der Blogreihe bei der Erstellung der SQL-Datenbank angegeben haben. Nun ist die Konfiguration abgeschlossen und wir können die Migration anstoßen.

In der NuGet-Package-Konsole (Tools -> NuGet Package Manager -> Package Manager Console) das Projekt Domain als Startprojekt festlegen und den Befehl Add-Migration InitialCreate -Context OKBLOGContext eingeben. Automatisch wird die Migrationsdatei im Projekt erzeugt und für eine Ausführung mit EntityFrameworkCore\Update-Database -Context OKBLOGContext bereitgestellt.

.....
name: "Restaurant",
columns: table => new
{
  Id = table.Column<Guid>(type: "uniqueidentifier", nullable: false),
    Name = table.Column<string>(type: "nvarchar(max)", nullable: true)
},
constraints: table =>
{
  table.PrimaryKey("PK_Restaurant", x => x.Id);
});
.....

Habt ihr alles richtig gemacht, sieht man im Query-Editor von Azure, dass die Tabellen tatsächlich angelegt und einsatzbereit sind.

So einfach und schnell ist die Erstellung von Datenbanktabellen in Azure mit dem Entity Framework.

Im nächsten Teil der Artikelserie implementieren wir die API für das spätere Frontend und schauen uns dabei das „Controller, Service und Repository“ Software Architektur Pattern genauer an.