Artikel
02/01/2017

Oktober 2016

Band 31, Nummer 10

Dieser Artikel wurde maschinell übersetzt.

Datenpunkte: Ausführen von EF Core für .NET Framework und .NET Core

Julie Lerman Anfang 2016 wurde die zuvor unter dem Namen Entity Framework 7 (EF7) bekannte Technologie in Entity Framework Core (EF Core) umbenannt. EF Core 1.0.0 führt einige überzeugende neue Funktionen ein, auch wenn die Featuresammlung insgesamt kleiner als EF6 ist. Dies bedeutet aber nicht, dass EF nur unter .NET Core ausgeführt werden kann. Sie können EF Core in APIs und Anwendungen einsetzen, die die vollständige Version von .NET Framework erfordern, sowie in Fällen, in denen nur die plattformübergreifende Version von .NET Core verwendet wird. In dieser Kolumne führe ich Sie schrittweise durch zwei Projekte, anhand derer diese Optionen erläutert werden. Mein Ziel dabei ist es, Befürchtungen zu zerstreuen, die der Name „Core“ möglicherweise hervorruft: dass EF nur unter .NET Core ausgeführt werden kann. Außerdem erläutere ich die Schritte, die zum Erstellen der einzelnen Lösungen erforderlich sind.

EF Core in vollständigen .NET-Projekten

Ich beginne mit einem Projekt für die vollständige Version von .NET Framework. Denken Sie daran, dass in Visual Studio 2015 die Toolinganforderungen Visual Studio 2015 Update 3 sowie die aktuellen Versionen von Microsoft ASP.NET und den Webtools sind. Zum Zeitpunkt der Artikelerstellung (August 2016) ist der beste Leitfaden für diese Installationen die Dokumentation unter bit.ly/2bte6Gu.

Damit der Datenzugriff getrennt von der App bleibt, die ihn verwendet, erstelle ich ihn in seiner eigenen Klassenbibliothek. Abbildung 1 zeigt, dass eine Vorlage speziell für eine .NET Core-Klassenbibliothek vorhanden ist. Ich wähle jedoch „Klassenbibliothek“ aus, die Standardoption, die immer für .NET verfügbar war. Das sich ergebende Projekt (Abbildung 2) ist ebenfalls „normal“. Sie sehen, dass keine Dateien „project.json“ oder .NET Core-Projektressourcen vorhanden sind. Alles sieht so aus wie immer.

Abbildung 1: Erstellen einer Klassenbibliothek für eine vollständige .NET-API

Abbildung 2: Eine altbekannte (und vertraute ) .NET-Klassenbibliothek

Bis jetzt steht nichts in irgendeiner Beziehung zu EF. An diesem Punkt könnte ich EF6 oder EF Core auswählen. Ich füge dem Projekt jedoch EF Core hinzu. Wie immer kann ich den NuGet-Paket-Manager oder das Paket-Manager-Konsolenfenster zum Suchen nach und Auswählen von EF Core verwenden. Ich entscheide mich für die Konsole. Denken Sie daran, dass das Paket „entityframework“ für EF6 gedacht ist. Damit EF Core verwendet wird, müssen Sie eines der Microsoft.EntityFrameworkCore-Pakete installieren. Ich verwende das SqlServer-Paket, das alles enthält, was für die Kommunikation von EF mit SqlServer erforderlich ist:

install-package Microsoft.EntityFrameworkCore.SqlServer

Da dieses Paket vom Microsoft.EntityFrameworkCore-Hauptpaket sowie vom Microsoft.EntityFrameworkCore.Relational-Paket abhängt, installiert NuGet zur gleichen Zeit auch diese Pakete für mich. Und da das EF Core-Paket von anderen Paketen abhängt, werden auch diese installiert. Insgesamt werden bei diesem Vorgang drei EF Core-Pakete sowie 23 weitere Pakete aus dem neueren und zusammensetzbareren .NET hinzugefügt, das EF Core verwendet. Anstatt wenigen großen Paketen erhalte ich mehr kleine Pakete, aber nur die Pakete, die meine Software benötigt. Diese funktionieren alle gut mit den bereits im Projekt vorhandenen .NET-Standardbibliotheken zusammen.

Im nächsten Schritt füge ich eine einfache Domänenklasse („Samurai.cs“) und einen DbContext („SamuraiContext.cs“) hinzu, damit EF Core meine Daten persistent in einer Datenbank speichert. Abbildung 3 zeigt dies. EF Core verfügt nicht wie EF6 über den magischen Verbindungszeichenfolgen-Rückschluss. Ich muss EF Core also wissen lassen, welchen Anbieter und welche Verbindungszeichenfolge ich verwende. Aus Gründen der Einfachheit füge ich diese Angaben direkt in der neuen virtuellen Methode von DbContext hinzu: „OnConfiguring“. Außerdem habe ich eine Konstruktorüberladung erstellt, damit ich bei Bedarf den Anbieter und andere Details übergeben kann. Ich werde dies in Kürze nutzen.

Abbildung 3: Samurai-Klasse und SamuraiContext DbContext-Klasse

public class Samurai
  {
    public int Id { get; set; }
    public string Name { get; set;}
  }
public class SamuraiContext : DbContext
  {
    public DbSet<Samurai> Samurais { get; set; }
    protected override void OnConfiguring(DbContextOptionsBuilder optionsBuilder) {
      {
        if (optionsBuilder.IsConfigured == false) {
          optionsBuilder.UseSqlServer(
         @"Data Source=(localdb)\\mssqllocaldb;Initial Catalog=EFCoreFullNet;
                       Integrated Security=True;");
        }
        base.OnConfiguring(optionsBuilder);
      }
    }
    public SamuraiContext(DbContextOptions<SamuraiContext> options)
      : base(options) { }
  }

Da ich vollständiges .NET verwende (was auch vollständiges Windows bedeutet), steht Windows PowerShell bereit. Und dies bedeutet wiederum, dass ich die gleichen Migrationsbefehle verwende, die ich schon immer verwende habe: „add-migration“, „update-database“ usw. Es sind auch einige neue Befehle verfügbar. In meiner Kolumne aus Januar 2016 (msdn.com/magazine/mt614250) finden Sie vollständige Informationen zu den EF Core-Migrationsbefehlen. Ich habe ja bereits oben erwähnt, dass die Pakete kleiner und zusammensetzbar sind. Wenn ich also Migrationen verwenden möchte, muss ich noch das Paket hinzufügen, das diese Befehle enthält. Während ich dies schreibe, befinden sich die Tools noch im Previewmodus. Ich muss also den Parameter „-pre“ verwenden. Ich füge das Paket hinzu. Jetzt kann ich eine neue Migration hinzufügen:

install-package Microsoft.EntityFrameworkCore.Tools –pre
add-migration init

Dies funktioniert wie immer: Es werden ein neuer Ordner „Migrations“ und die Migrationsdatei erstellt. Abbildung 4 zeigt dies. In EF Core wurde geändert, wie Modellmomentaufnahmen gespeichert werden. Informationen dazu finden Sie in der oben genannten Kolumne aus Januar 2016.

Abbildung 4: EF Core-Migrationen in meine vollständige .NET-Klassenbibliothek

Nachdem diese Migration ausgeführt wurde, erstellt der Befehl „update-database“ erfolgreich die neue EFCoreFullNet-Datenbank für mich in localdb von SQL Server.

Schließlich füge ich der Lösung noch ein Testprojekt aus der gleichen Vorlage „Komponententestprojekt“ hinzu, die ich immer in Visual Studio verwendet habe. Dann füge ich einen Verweis auf meine EFCoreFullNet-Klassenbibliothek hinzu. Es ist nicht erforderlich, dass mein Testprojekt die Datenbank zum Sicherstellen verwendet, dass EF Core funktioniert. Anstatt also das SqlServer-Paket zu installieren, führe ich den folgenden NuGet-Befehl für das neue Testprojekt aus:

install-package microsoft.EntityFrameworkCore.InMemory

Der InMemory-Anbieter ist für das Testen mit EF Core ein Glücksgriff. Er verwendet die In-Memory-Daten zum Darstellen der Datenbank und des EF-Caches. EF Core interagiert mit dem Cache auf sehr ähnliche Weise wie mit der Datenbank beim Hinzufügen, Entfernen und Aktualisieren von Daten.

Erinnern Sie sich an den zusätzlichen Konstruktor, den ich in „SamuraiContext“ erstellt habe? Die in Abbildung 5 gezeigten TestEFCoreFullNet-Tests nutzen ihn. Beachten Sie, dass ich im Konstruktor der Testklasse einen DbContextOptions-Builder für „SamuraiContext“ erstellt und dann angegeben habe, dass er den InMemory-Anbieter verwenden soll. Beim Instanziieren von „SamuraiContext“ übergebe ich dann diese Optionen in der Methode. Die OnConfiguring-Methode von „SamuraiContext“ soll überprüfen, ob die Optionen bereits konfiguriert sind. Wenn dies der Fall ist, verwendet die Methode sie (hier den InMemory-Anbieter). Andernfalls arbeitet sie mit SqlServer der Verbindungszeichenfolge, die ich in die Methode hartcodiert habe.

Abbildung 5: Testen mit EFCore

using EFCoreFullNet;
using Microsoft.EntityFrameworkCore;
using Microsoft.VisualStudio.TestTools.UnitTesting;
using System.Linq;
namespace Tests
{
  [TestClass]
  public class TestEFCoreFullNet
  {
    private DbContextOptions<SamuraiContext> _options;
    public TestEFCoreFullNet() {
      var optionsBuilder = new DbContextOptionsBuilder<SamuraiContext>();
      optionsBuilder.UseInMemoryDatabase();
      _options = optionsBuilder.Options;
    }
    [TestMethod]
    public void CanAddAndUpdateSomeData() {
      var samurai = new Samurai { Name = "Julie" };
      using (var context = new SamuraiContext(_options)) {
        context.Add(samurai);
        context.SaveChanges();
      }
      samurai.Name += "San";
      using (var context = new SamuraiContext(_options)) {
        context.Samurais.Update(samurai);
        context.SaveChanges();
      }
      using (var context = new SamuraiContext(_options)) {
        Assert.AreEqual("JulieSan", context.Samurais.FirstOrDefault().Name);
      }
    }
  }
}

Diese Testmethode nutzt einige spezifische EF Core-Features, die in EF6 nicht vorhanden sind. Ich habe diese und einige andere Features für die Änderungsnachverfolgung in EF Core in meiner Datenpunkt-Kolumne aus August 2016 (msdn.com/magazine/mt767693) behandelt. Nach dem Erstellen des neuen samurai-Objekts füge ich es dem Kontext mithilfe der DbContext.Add-Methode hinzu. EF kann dann ermitteln, an welches DbSet das Objekt gebunden werden muss. Dies speichere ich dann im Datenspeicher. In diesem Fall handelt es sich um einen Typ von Liste im Arbeitsspeicher, die der InMemory-Anbieter verwaltet. Im nächsten Schritt ändere ich das samurai-Objekt, erstelle eine neue Instanz von DbContext und verwende den neuen Befehl „Update“ von EF Core zum Sicherstellen, dass „SaveChanges“ das gespeicherte samurai-Objekt aktualisiert und kein neues Objekt erstellt. Schließlich frage ich den Kontext auf dieses samurai-Objekt ab und verwende eine Assertion zum Sicherstellen, dass der Kontext tatsächlich den aktualisierten Namen zurückgibt.

Es geht aber nicht um die jeweiligen Features, die ich verwende. Der Punkt ist, dass ich alle diese Aufgaben mit EF Core in einem „herkömmlichen“ .NET-Projekt in Windows ausführe.

EF Core für CoreCLR: Gleicher Code, andere Abhängigkeiten

Ich könnte Windows und Visual Studio 2015 Update 3 weiterhin verwenden, um Ihnen nun zu zeigen, wie ich die gleichen EF Core-APIs, den gleichen Code und die gleichen Tests für die CoreCLR-Laufzeit verwende. Das würde aber der Vorgehensweise für Windows zu sehr gleichen. Also schwenke ich in das andere Extrem um und erstelle die CoreCLR-Variante auf meinem MacBook und erläutere dabei die einzelnen Schritte.

.NET Core ist nicht von Windows oder den zugehörigen Tools abhängig. Was könnte ich außer Visual Studio 2015 verwenden? Nun, ich glaube, Emacs war ein häufig eingesetzter alter Nicht-Visual Studio-Editor. Ich kann jedoch unter einigen plattformübergreifenden IDEs auswählen. Und das nicht nur zum Schreiben des Codes, sondern auch zum Nutzen von Features wie Debuggen und Git-Unterstützung. In der Ausgabe von MSDN Magazine aus August 2016 hat Alessandro Del Sole z. B. das schrittweise Erstellen einer ASP.NET Core-Website mithilfe von Visual Studio Code (msdn.com/magazine/mt767698) erläutert. An seinen Screenshots konnte ich erkennen, dass er Windows verwendet hat. Die Benutzererfahrung ist auf einem Mac jedoch im Wesentlichen die gleiche.

Eine weitere plattformübergreifende Option ist Rider von JetBrains. Rider wurde speziell für C# konzipiert und kann am besten als „ReSharper in einer eigenen IDE“ beschrieben werden.

Ich habe bereits Visual Studio Code unter Windows und OS X verwendet (nicht nur für C#, sondern auch für Node.js). Diese Anwendung nutze ich nun auch, um Ihnen EF Core in einer App zu zeigen, die für CoreCLR erstellt wurde. Da ich diese Lösung unter OS X erstelle, ist CoreCLR tatsächlich meine einzige Option. Die Sammlung der verfügbaren APIs für meine Bibliothek ist eingeschränkter. EF Core enthält jedoch die gleiche Sammlung von APIs wie in der vollständigen .NET-Bibliothek, die ich im ersten Projekt verwendet habe.

Sie werden sehen, dass das Einrichten der Projekte und Abhängigkeiten, die spezifisch für CoreCLR sind, den meisten Aufwand verursacht. Ich kann aber die gleiche SamuraiContext-Klasse zum Definieren meines EF Core-Datenmodells und die gleiche CanAddAndUpdateSomeData-Testmethode aus dem vorherigen Projekt verwenden, um die gleichen Aufgaben auszuführen. Der Code ist identisch, obwohl das Ziel jetzt die eingeschränktere Laufzeit ist und ich in einer Umgebung arbeite, in der nichts außer .NET Core verwenden kann.

Erstellen einer Bibliothek, die der .NET -Klassenbibliothek ähnelt

Ich habe einen Ordner mit Unterordnern für jedes Projekt erstellt, der meine Bibliothek und die Testprojekte enthält. Im Unterordner „Library“ kann ich „dotnet new“ aufrufen, um das Bibliotheksprojekt zu erstellen. Abbildung 6 zeigt diesen Befehl sowie eine Bestätigung, dass das Projekt erstellt wurde. Das Auflisten der Inhalte des Ordners zeigt, dass nur zwei Dateien erstellt wurden. Die wichtigste davon ist die Datei „project.json“, die die Liste der erforderlichen NuGet-Pakete und andere relevante Projektdetails enthält. Die Datei „Library.cs“ ist einfach eine leere Klassendatei, die ich lösche.

Abbildung 6: Erstellen einer neuen CoreCLR-Bibliothek mit dem dotnet-Befehl

Im nächsten Schritt öffne ich dieses neue Bibliotheksprojekt in Visual Studio Code. Ich kann an der Eingabeaufforderung einfach „code“ eingeben. Visual Studio Code wird mit diesem Ordner als Zielordner geöffnet, die in der JSON-Datei aufgelisteten Pakete werden automatisch erkannt, und es wird angeboten, den Befehl „dotnet restore“ auszuführen, um die nicht aufgelösten Abhängigkeiten zu beheben. Ich nehme dieses Angebot gern an.

Die Datei „project.json“ sieht wie der Code in Abbildung 7 aus.

Abbildung 7: Die Datei „project.json“

{
  "version": "1.0.0-*",
  "buildOptions": {
    "debugType": "portable"
  },
  "dependencies": {},
  "frameworks": {
    "netstandard1.6": {
      "dependencies": {
        "NETStandard.Library": "1.6.0"
      }
    }
  }
}

Ziemlich einfach. Bibliotheken benötigen nicht die ganzen ASP.NET Core-Elemente, die ich für gewöhnlich verwende, sondern nur die NETStandard-Bibliothek. Die .NET-Standardbibliothek kapselt alle Gemeinsamkeiten der verschiedenen Plattformen, unter denen .NET jetzt ausgeführt werden kann. Die .NET-Standarddokumentation (bit.ly/2b1JoHJ) besagt Folgendes: „Die .NET-Standardbibliothek ist eine formale Spezifikation von .NET-APIs, die für alle .NET-Laufzeiten zur Verfügung stehen sollen“. Die Bibliothek, die ich erstelle, kann daher mit .NET Core-, ASP.NET Core- und sogar mit .NET-Anwendungen ab .NET 4.5 verwendet werden. Ein Kompatibilitätsraster finden Sie auf der Dokumentationsseite.

Der nächste Schritt besteht im Hinzufügen von EF Core zum Projekt. Denken Sie daran, dass SqlServer keine Option ist, da ich mit einem Mac arbeite. Ich verwende stattdessen den PostgreSQL-Anbieter für EF Core und füge ihn in den zurzeit leeren Abschnitt „dependencies“ der Datei „project.json“ ein:

"dependencies": {
    "Npgsql.EntityFrameworkCore.PostgreSQL": "1.0.0-*"   
  },
  "tools": {
    "Microsoft.EntityFrameworkCore.Tools": "1.0.0-preview2-final"
  },

Wie schon zuvor, plane ich erneut Migrationen. Normalerweise würde ich wie bei der vollständigen .NET-Version dieser Bibliothek auch eine Abhängigkeit für das Microsoft.EntityFrameworkCore.Tools-Paket hinzufügen, das die Befehle enthält. Aufgrund der aktuellen Einschränkung der Preview 2-Tools verschiebe ich dies jedoch auf einen späteren Schritt in diesem Vorgang. Ich muss jedoch in der Lage sein, auf die Befehle aus dem Ordner dieser Bibliothek zuzugreifen. Ich füge das Paket daher einem besonderen Abschnitt „tools“ in der Datei „project.json“ (wie im Code oben gezeigt) hinzu.

Das Wiederherstellen der Pakete integriert nicht nur diese Pakete, sondern auch deren Abhängigkeiten. Wenn Sie die Datei „project.lock.json“ einchecken, die erstellt wird, werden alle Pakete (einschließlich „Microsoft.EntityFrameworkCore“ und „Microsoft.EntityFrameworkCore.Relational“) angezeigt. Es handelt sich um die gleichen Pakete, die der weiter oben beschriebenen .NET-Lösung hinzugefügt wurden.

Nun kopiere ich einfach meine Dateien „Samurai.cs“ und „SamuraiContext.cs“ in den Ordner. Ich muss die OnConfiguring-Klasse so ändern, dass „PostgreSQL“ und die zugehörige Verbindungszeichenfolge anstelle von SQL Server verwendet werden. Der Codeausschnitt sieht nun folgendermaßen aus:

optionsBuilder.UseNpgsql(
  "User ID=julie;Password=12345;Host=localhost;Port=5432;Database=EFCoreCoreCLR;
    Pooling=true;");

Es wäre an der Zeit, jetzt die Migrationen auszuführen. Es trifft aber eine bekannte Einschränkung der aktuellen Preview2-Version der EFCore-Tools außerhalb von Visual Studio zu: Ein ausführbares Projekt ist erforderlich, damit wichtige Ressourcen gefunden werden. Das ist auf den ersten Blick unerfreulich, bedeutet aber nicht allzu viel Mehraufwand. Weitere Informationen hierzu finden Sie unter bit.ly/2btm4OW.

Erstellen des Testprojekts

Im nächsten Schritt füge ich mein Testprojekt hinzu, das ich anschließend als ausführbares Projekt für die Migrationen verwenden kann. Zurück in der Befehlszeile wechsele ich in den Unterordner „Oct2016DataPointsMac/Test“, den ich zuvor erstellt habe, und führe Folgendes aus:

dotnet new -t xunittest

In Visual Studio Code wird nun die neue Datei „project.json“ im Ordner „Test“ aufgelistet. Da dieses Projekt für das Sicherstellen verantwortlich sein wird, dass die EF-Befehlszeilen ausgeführt werden können, müssen Sie den Abhängigkeiten einen Verweis auf die EF Core Tools-Pakete hinzufügen. Außerdem benötigt das Testprojekt einen Verweis auf die Bibliothek. Diesen habe ich den Abhängigkeiten von „project.json“ ebenfalls hinzugefügt. Der Abschnitt „dependencies“ sieht nach dem Hinzufügen wie folgt aus:

"dependencies": {
    "System.Runtime.Serialization.Primitives": "4.1.1",
    "xunit": "2.1.0",
    "dotnet-test-xunit": "1.0.0-rc2-192208-24",
    "Library": "1.0.0",
    "Microsoft.EntityFrameworkCore.Tools": "1.0.0-preview2-final"
  },

Nun kann ich auf die EF Core-Befehle aus meinem Ordner „Library“ zugreifen. Beachten Sie, dass in Abbildung 8 der Befehl mit dem Parameter „--startup-project“ auf das Projekt im Ordner „Test“ verweist. Ich verwende diesen Parameter mit jedem der Migrationsbefehle.

Abbildung 8: Nutzen eines ausführbaren Projekts zum Aktivieren der Bibliothek für die Verwendung der EF-Migrationsbefehle

Ausführen von Migrationen für das EF-Model- aus der .NET-Bibliothek

Denken Sie daran, dass die „dotnet ef“-Migrationsbefehle anders als die PowerShell-Befehle aussehen (siehe meine Kolumne zu EFCore-Migrationen). Sie führen jedoch zu der gleichen Programmlogik in der Migrations.API.

Zuerst erstelle ich die Migration:

dotnet ef --startup-project ../Test migrations add init

Die Ergebnisse sind mit den Ergebnissen in de .NET-Lösung identisch: ein neuer Ordner „Migrations“, dem die Migration und die Migrationsmomentaufnahme hinzugefügt wurden.

Nun kann ich die Datenbank erstellen:

dotnet ef --startup-project ../Test database update

Ich stelle anschließend durch Überprüfen sicher, dass die PostgreSQL-Datenbank, -Tabellen und -Beziehungen erstellt wurden. Zu diesem Zweck stehen in OS X mehrere Tools zur Verfügung. Auf meinem Mac verwende ich das plattformübergreifende Tool DataGrip von JetBrains als meine Datenbank-IDE.

Ausführen der Tests in CoreCLR

Schließlich kopiere ich die TestEFCoreFullNet-Klasse aus der vorherigen Lösung in meinen Ordner „Test“. Erneut muss ich Infrastrukturänderungen vornehmen, um „xUnit“ anstelle von „MS Test“ zu verwenden: einige Namespaceänderungen, Entfernen des TestClass-Attributs, Ersetzen der TestMethod-Attribute durch „Fact“ und Ersetzen von „Assert.AreEqual“ durch „Assert.Equal“. Natürlich benenne ich die Klasse auch in „TestEFCoreCoreClr“ um.

„Project.json“ muss außerdem den InMemory-Anbieter kennen. Ich füge daher Folgendes:

"Microsoft.EntityFrameworkCore.InMemory": "1.0.0"

auch dem Abschnitt „dependencies“ hinzu und führe dann „dotnet restore“ erneut aus.

Mein xUnit-Testprojekt verwendet den xUnit-Befehlszeilen-Test Runner. Also wechsele ich zurück in mein Terminalfenster, um die Tests mit dem Befehl „dotnet test“ auszuführen. Abbildung 9 zeigt die Ausgabe der Testausführung, die mit den richtigen Farben bestanden wurde. Nur der Befehlszeilen-Test Runner zeigt nicht die grüne Ausgabe für erfolgreich bestandene Tests an.

Abbildung 9: xUnit-Testausgabe des bestandenen Tests

.NET oder CoreCLR: gleiche APIs, gleicher Code

Ich habe gezeigt, dass der Code und die Assemblys, die sich auf EF Core beziehen, unabhängig davon identisch sind, ob die Software nur unter Windows mit vollständigem .NET Framework oder unter CoreCLR in einer der unterstützten Umgebungen (Linux, OS X, Windows) ausgeführt werden soll. Ich hätte beide Beispiele in Visual Studio 2015 auf meinem Windows-Computer ausführen können. Ich denke aber, dass sich mithilfe der Ausführung der CoreCLR-Aufgaben in einer Umgebung, die für vollständiges .NET Framework überhaupt nicht verfügbar ist, auf eindrucksvolle Weise zeigen lässt, dass die EF-APIs und mein EF-bezogener Code in beiden Szenarien identisch sind. Die großen Unterschiede und alle Zusatzaufgaben beziehen sich nur auf die Zielplattformen (.NET im Vergleich zu CoreCLR). Den Erstellungsvorgang einer vollständigen ASP.NET Core-Web-API mit EF Core 1.0.0 auf meinem MacBook können Sie im Video „First Look at EF Core 1.0” (bit.ly/2cmblqE) verfolgen. Eine verkürzte, unterhaltsame Fassung zum gleichen Thema finden Sie im Video meiner DotNetFringe-Sitzung unter bit.ly/2ci7q0T.

Julie Lerman ist Microsoft MVP, .NET-Mentorin und Unternehmensberaterin. Sie lebt in den Bergen von Vermont. Sie hält bei User Groups und Konferenzen in der ganzen Welt Vorträge zum Thema Datenzugriff und anderen .NET-Themen. Julie Lerman führt unter thedatafarm.com/blog einen Blog. Sie ist die Autorin von „Programming Entity Framework“ sowie der Ausgaben „Code First“ und „DbContext“ (alle bei O’Reilly Media erschienen). Folgen Sie ihr auf Twitter: @julielerman, und sehen Sie sich ihre Pluralsight-Kurse unter juliel.me/PS-Videos an.

Unser Dank gilt dem folgenden technischen Experten bei Microsoft für die Durchsicht dieses Artikels: Jeff Fritz
Jeffrey T. Fritz ist ein Senior Program Manager im ASP.NET-Team von Microsoft und arbeitet an Web Forms und ASP.Net Core. Als langjähriger Webentwickler mit Erfahrung in großen und kleinen Anwendungen in einer Vielzahl von Branchen weiß er, wie wichtig die Aspekte Leistung und Praktikabilität bei der Entwicklung sind.