Data Points

Artikel
01/29/2015

Ausblick auf Entity Framework 7

Julie Lerman Die Entwicklung der nächsten Version von Entity Framework kommt gut voran. Einen ersten Blick auf das, woran das EF-Team arbeitet, konnte ich auf der TechEd North America 2014 werfen, wo Programm-Manager Rowan Miller über die Ziele für Entity Framework 7 (EF7) sprach und einige Dinge in einem sehr frühen Stadium zeigte.

Während ich diese Kolumne schreibe, sind seitdem fünf Monate vergangen, und obgleich EF7 immer noch im frühen Alpha-Stadium ist, ist einiges passiert. In dieser Kolumne möchte ich Ihre Aufmerksamkeit darauf richten, was Entwickler von EF7 zu erwarten haben, welche Motivation hinter den Entscheidungen steckt, die für EF7 getroffen wurden, und was diese Version für bestehende Apps bedeutet, die EF6 oder niedriger verwenden. Außerdem werde ich Ihnen einen Einblick in Teile des Codes gewähren.

Open Source, aber jetzt auf GitHub

Als Erstes sollten Sie über EF7 erfahren, dass es – wie EF6 – Open Source ist. Aber statt auf CodePlex entwickelt zu werden, befindet sich EF7 auf GitHub, zusammen mit dem Rest der zukünftigen Version von ASP.NET. Die URL für die EF7-Entwicklung lautet github.com/aspnet/EntityFramework. Wie bei EF6 können Sie die Details von EF7 während ihrer Entwicklung beobachten. Sie können den Quellcode untersuchen sowie seine Fortschritte durch Zweige (Branches) und Commits verfolgen, den Diskussionen folgen, Probleme melden, Quellcode abspalten (Forks), und Pull-Anforderungen zur Untersuchung und für potenzielle Commits in die Codebasis an das Team senden.

EF6 verschwindet nicht in absehbarer Zeit

Machen Sie sich keine Sorgen – Sie werden nicht gezwungen, auf EF7 umzustellen. Denken Sie zurück an ADO.NET DataSets und DataReaders. Ganz ähnlich wie ASP.NET-Webformulare, die immer noch unterstützt werden und sogar von gelegentlichen Anpassungen profitieren, ist ADO.NET weiterhin Bestandteil des Microsoft .NET Framework, sogar obwohl EF nun schon seit Jahren die primäre Technologie für den Datenzugriff in .NET ist. Es wurde nicht viel unternommen, um diese Technologien zu verbessern, aber sie sind immer noch da und unterstützen eine Menge Legacycode (inkl. meines eigenen). Einer der großen Vorteile von EF6 gegenüber diesen anderen Technologien ist, dass es Open Source ist. Hierdurch kann, wenn auch das Team bei Microsoft nicht mehr viel in EF6 investieren wird, die Community dies selbst übernehmen. Und das EF-Team fühlt sich EF6 verpflichtet. Es wird weiterhin Anpassungen vornehmen, Pull-Anforderungen genau untersuchen und EF6 aktualisieren. Sogar obwohl sie einen Großteil von 2014 mit vollem Einsatz an EF7 gearbeitet haben, wurde EF6 aktualisiert. Version 6.1.0 wurde im Februar 2014 veröffentlicht, 6.1.1 im Juni 2014, und während ich diesen Artikel schreibe, befindet sich 6.1.2 im Beta-Stadium und soll bald veröffentlicht werden. Ursprünglich war ich besorgt, ob ich ältere Apps weiterhin lauffähig erhalten könnte, aber das hat sich gegeben. Die Einzigen, um die ich mir noch Sorgen machen würde, sind die ersten Apps, die EF zusammen mit .NET Framework 3.5, ObjectContext usw. verwenden. Aber wenn Sie diese Apps noch nicht aktualisiert haben, um all die großen Verbesserungen an EF im Laufe der Jahre zu nutzen, kümmern Sie sich vermutlich sowieso nicht allzu sehr um EF7. Sie können auch alle früheren Pakete von EF auf NuGet finden, bis zurück zu EF 4.1.10311.

EF7: Die kurze Liste

Hier finden Sie jetzt die Zusammenfassung der Neuerungen in EF7:

Unterstützung für nicht relationale Datenspeicher und sogar für speicherinterne Daten zum Testen.
Unterstützung für Computer und Geräte, die nicht das vollständige .NET Framework nutzen. Das bedeutet, dass Sie EF7 in Windows Phone- und Windows Store-Apps sowie auf Linux- und Macintosh-Computern, die Mono ausführen, verwenden können.
Unterstützung für zahlreiche Funktionen, die Entwickler gefordert haben, die aber mit der bisherigen Codebasis nicht realisiert werden konnten.
Fortgesetzte Unterstützung für Anwendungen, die das vollständige .NET Framework nutzen, z. B. Windows Presentation Foundation und andere Clientanwendungen.
EF7 wird auf dieselbe Weise verteilt wie ASP.NET 5 und kann mit ASP.NET 5-Apps verwendet werden.

Vertraute Programmieroberfläche, neue Codebasis

Jede Version von EF hat das Framework weiterentwickelt, indem neue Funktionen hinzugefügt und Leistung und APIs optimiert wurden. Wie ich bereits in dieser Kolumne sowie in einem Übersichtsartikel in der Dezember-Ausgabe 2013, "Entity Framework 6: Die Ninja-Edition” (bit.ly/1cwjyCD), geschrieben habe, hat die letzte Version EF auf eine ganz neue Ebene gehoben, indem das Framework um zahlreiche Funktionen erweiterte wurde, die von den Benutzern im Verlauf der Entwicklung gefordert wurden, so zum Beispiel die asynchrone Datenbankausführung, Erschließen der Abfragepipeline, Anpassen von Code First-Konventionen und vieles mehr. Auf diese Funktionen gehe ich wesentlich detaillierter in meinem Pluralsight-Kurs "Entity Framework 6, Ninja Edition: What’s New in EF6" (bit.ly/PS-EF6) ein.

Es gab sogar noch mehr von Entwicklern für EF gewünschte Funktionen, die Microsoft implementieren wollte, doch die mehr als 10 Jahre alte Codebasis, auf der EF basiert – mit andauernder Abhängigkeit von ObjectContext- und weniger flexiblen Codierungsmustern – hat verhindert, dass das Team einen weiteren Entwicklungssprung bei den Funktionen verwirklichen konnte. Die schwierige Entscheidung, mit der sicherlich schon viele von Ihnen bei Ihrem Legacycode konfrontiert wurden, wurde getroffen, Entity Framework vollständig neu zu entwickeln.

EF7 erstellt kein neues Framework für den Datenzugriff. Stattdessen erzeugt es eine neue, nachhaltigere Basis, auf deren Grundlage nicht nur die Funktionen und Workflows unterstützt werden, auf die Sie sich seit Jahren bei EF verlassen, sondern auch neue, die Ihnen ganz neue Möglichkeiten eröffnen. Das Team hat sichtlich mit der Entscheidung gekämpft, ob dies das neue EF oder eine neue Technologie für den Datenzugriff werden sollte. An einem Punkt habe ich mich sogar gefragt, ob es "EF Light" werden würde. Aber die Kernfunktionalitäten von EF sind immer noch vorhanden und nach vielen Abwägungen muss ich zustimmen, dass es sinnvoll ist, von der nächsten Version von Entity Framework zu sprechen. Weitere Informationen hierzu finden Sie im Blogbeitrag des Teams "EF7 – v1 oder v7?" (bit.ly/1EFEdRH).

Legacyballast abwerfen – was gut ist, behalten

Es gibt dennoch Neuerungen bei EF7, bei denen sich manche Entwickler Sorgen machen. Zwar bleiben die meisten gängigen EF-Klassen, -Muster und -Workflows erhalten, doch einiger der seltener verwendeten Elemente bleiben auf der Strecke. Aber keine Panik bitte! Ich gehe gleich noch ausführlicher darauf ein.

Ein kritisches Ziel war es, Entwicklern die Möglichkeit zu geben, weiterhin vertraute Muster benutzen und gleichzeitig noch große Mengen von vorhandenem Code nach EF7 portieren zu können. Sie werden DbContext, DbSet, LINQ-Abfragen, SaveChanges und viele andere Interaktionsmittel, die Bestandteil von EF waren, noch eine ganze Weile benutzen.

Sehen Sie beispielsweise hier eine DbContext-Klasse, die ich in EF7 definiert habe:

public class BreweryContext : DbContext {
  public DbSet<Brewery> Breweries { get; set; }
  public DbSet<Beer> Beers { get; set; }
}

Und hier eine einfache Aktualisierung in EF7, die mit der Version in EF6 identisch ist. Ich verwende einen synchronen Speichervorgang, aber auch all die asynchronen Methoden sind vorhanden:

public void StoreBeers(List<Beer> beers) {
  using (var context = new BreweryContext()) {
    context.Beers.AddRange(beers);
    context.SaveChanges();
  }
}

Und eine einfache Abfrage:

using (var context = new BreweryContext()) {
       return context.Breweries.Where(b=>b.Location.Contains("Vermont"));
}

Ich verwende die Version von EF7, die in den Paketen der Version beta2-11616 enthalten ist. EF7 ist im Moment noch nicht wirklich Beta, aber das "beta2" hängt mit einer Benamungsentscheidung für NuGet-Pakete zusammen. Zum Zeitpunkt der Veröffentlichung dieses Artikels wird sich EF7 schon weiter entwickelt haben. Betrachten Sie dies also nur als eine Aussicht, kein Versprechen.

Ich verwende immer noch einen DbContext und definiere DbSets, ganz wie bisher. Auch OnModelCreating ist noch vorhanden, wenn ich es hier auch nicht verwende.

Mit EF4.1 wurde die DbContext-API eingeführt, die sich wesentlich stärker auf die typische EF-Verwendung konzentrierte. Darunter basierte sie immer noch auf dem ursprünglichen ObjectContext, der Datenbankinteraktion bereitstellt, Transaktionen verwaltet und den Zustand von Objekten verfolgt. Seit dieser Zeit hat sich DbContext zur Standardklasse entwickelt, und Sie würden zu den APIs niedrigerer Ebenen greifen, wenn Sie eine seltene Interaktion mit ObjectContext ausführen wollten. EF7 wird die übergewichtige ObjectContext abstoßen, und nur DbContext bleibt übrig. Aber einige dieser Aufgaben, bei denen Sie sich bisher auf ObjectContext verlassen haben, bleiben weiterhin verfügbar.

Manche der sehr komplizierten Zuordnungen, die schwierig zu unterstützen sind und nicht häufig verwendet werden, verschwinden mit EF7. In dem zuvor erwähnten Blogbeitrag heißt es: "Beispielsweise können Sie eine Vererbungshierarchie haben, die TPH-, TPT- und TPC-Zuordnungen kombiniert sowie Entitätsaufteilung, und alles in derselben Hierarchie." Wenn Sie jemals versucht haben, direkt mit der MetadataWorkspace-API zu arbeiten und schreiend davongelaufen sind, wissen Sie, dass es sich um ein verzwicktes und komplexes Monster handelt, das bei der Unterstützung dieser Art von Flexibilität nützlich ist. Diese Komplexität aber hat das Team daran gehindert, weitere Szenarios zu unterstützen, die von Benutzern gefordert wurden. Durch eine Vereinfachung der Zuordnungsmöglichkeiten wurde die MetadataWorkspace-API ebenfalls einfacher und wesentlich flexibler. Sie können ganz einfach über Ihr Modellschema aus der DbContext-API in EF7 auf Metadaten zugreifen, wodurch Sie über eine Funktion auf niedriger Ebene verfügen, um erweiterte Methoden anzuwenden, ohne ObjectContext auf niedriger Ebene zur Verfügung haben zu müssen.

EDMX entfällt, aber Database First bleibt

Entity Framework verfügt zurzeit über zwei Methoden zum Beschreiben eines Modells. Die eine verwendet eine EDMX im Designer, die andere verwendet die Klassen, einen DbContext und Zuordnungen, die von den Code First-APIs verwendet werden. Wenn Sie EDMX und den Designer verwenden, erstellt EF zur Laufzeit ein speicherinternes Modell aus dem XML-Code, der dem EDMX zugrunde liegt. Wenn Sie den Code First-Pfad wählen, erstellt EF dasselbe speicherinterne Modell, indem es die Klassen, den DbContext und die Zuordnungen einliest, die Sie bereitgestellt haben. Ab diesem Punkt arbeitet EF identisch, egal, wie Sie Ihr Modell beschreiben. Beachten Sie, dass Sie bei dem EDMX/Designer-Workflow ebenfalls POCO-Klassen und einen DbContext erhalten, mit denen Sie in Ihrem Code arbeiten können. Da aber das EDMX da ist, werden sie nicht verwendet, um dieses speicherinterne Modell zu erstellen. Dies zu verstehen ist wichtig, wenn Sie die folgenden Sätze lesen: EF7 unterstützt nicht das Designer-basierte EDMX-Modell. Es verfügt nicht über die Möglichkeit zum Lesen des EDMX-XML-Codes zur Laufzeit, um das speicherinterne Modell zu erstellen. Es verwendet nur den Code First-Workflow.

Als das Team dies im Blog veröffentlichte, machte sich Panik unter den Entwicklern breit. Teilweise verursacht durch die Tatsache, dass viele immer noch nicht erkannt haben, dass sie eine Datenbank in POCO-Klassen, DbContext und Zuordnungen zurückentwickeln können. Mit anderen Worten, Sie können bei einer Datenbank anfangen, um ein Code First-Modell zu erhalten. Dies ist möglich, seit die EF Power Tools Beta zum ersten Mal im Frühjahr 2011 veröffentlicht wurde. Es wird vom EF6.1-Designer unterstützt und wird auch definitiv in EF7 unterstützt werden. Ich habe schon oft gesagt, dass der "Code First"-Moniker ist ein bisschen verwirrend und irreführend. Ursprünglich wurde er "Code Only" genannt, aber der Name wurde in "Code First" geändert, um einheitlich mit "Database First" und "Model First" zu sein.

Somit benötigen Sie also nicht den Designer oder ein EDMX, um mit einer vorhandenen Datenbank zu beginnen.

Aber was ist, wenn Sie bestehende EDMX-Modelle haben und nicht die Möglichkeit verlieren möchten, einen Designer zu verwenden? Es gibt Designer von Drittanbietern, die Entity Framework unterstützen, z. B. den LLBLGen Pro Designer, der bereits EF Code First (bit.ly/11OLlN2) unterstützt, sowie den Devart Entity Developer (bit.ly/1yHWbB2). Suchen Sie nach diesen und möglicherweise anderen Tools, um potenzielle Designer-Unterstützung für EF7 bereitzustellen.

Da gibt es aber noch einen anderen beachtenswerten Pfad: einfach bei EF6 bleiben!

Schlanker, mehr Geräte und Betriebssysteme

Zusätzlich wollte Microsoft die Distribution der EF-APIs optimieren. Der NuGet-Paketordner für EF6.1.1 ist ca. 22 MB groß. Dies beinhaltet eine 5,5-MB-Assembly für .NET Framework 4.5 und eine weitere für den Fall, dass Sie .NET Framework 4 verwenden. Bei EF7 gibt es eine Reihe kleinerer DLLs. Sie kombinieren nur die DLLs, die zur Unterstützung Ihres Workflows notwendig sind. Wenn Sie beispielsweise für SQL Server programmieren, verwenden Sie eine Kern-"EntityFramework.dll", eine DLL für SQL Server sowie eine weitere mit APIs, die für relationale Datenspeicher gängig ist. Wenn Sie Migrationen verwenden möchten, ist dies eine gesonderte Assembly, die Sie vergessen können. Andernfalls können Sie Migrationen von der Paket-Manager-Konsole aus erstellen und ausführen. Dort gibt es eine API für Befehle. Wenn Sie den NuGet-Paket-Manager verwenden, werden die entsprechenden Pakete anhand ihrer Abhängigkeiten identifiziert und heruntergeladen, sodass Sie sich keine Gedanken über die Details machen müssen.

Der Effekt hiervon ist, dass EF7 auf dem Computer oder Gerät des Endbenutzers weniger Platz einnimmt, was besonders auf Geräten wichtig ist. ASP.NET bewegt sich in dieselbe Richtung. Beide dieser Technologien verzichten auf ihre Abhängigkeit vom vollen Umfang des .NET Framework. Stattdessen verteilen sie nur die DLLs, die notwendig sind, um die Aufgaben einer bestimmten Anwendung zu erledigen. Das bedeutet, dass die bereits optimierte Version von .NET, die von Windows Phone- und Windows Store-Apps verwendet wird, in der Lage sein wird, EF7 zu verwenden.

Es bedeutet ferner, dass Betriebssysteme wie OS X und Linux, die anstelle des vollständigen .NET Framework Mono verwenden, ebenfalls in der Lage sein werden, Entity Framework clientseitig zu unterstützen.

Mehr als relational

Als Entity Framework erstmalig eingeführt wurde, hatte Microsoft die Vision, dass es für eine Vielzahl verschiedener Datenspeicher verwendet würde, obwohl sich die erste Ausgabe auf relationale Datenbanken konzentrierte. Nicht relationale Datenbanken gab es zwar zu dieser Zeit, aber sie waren nicht sehr verbreitet in der Anwendung – im Gegensatz zu NoSQL-Datenbanken, insbesondere Dokumentendatenbanken, die heute so beliebt sind.

Zwar ist EF ein objektrelationaler Mapper (ORM), doch Entwickler, die es verwenden, möchten in der Lage sein, dieselben Konstrukte für die Interaktion mit nicht relationalen Datenbanken zu verwenden. EF7 bietet ein hohes Maß an Unterstützung hierfür, doch bedenken Sie dabei, was hohes Maß wirklich heißt. Es gibt große Unterschiede zwischen relationalen Datenbanken und nicht relationalen Datenbanken, und EF wird keinen Versuch unternehmen, diese Unterschiede zu verschleiern. Für grundlegende Abfragen und Aktualisierungen werden Sie allerdings in der Lage sein, dieselben Muster zu verwenden, mit denen Sie bereits vertraut sind.

Abbildung 1 zeigt Code aus einer Beispiel-App, die für Microsoft Azure-Tabellenspeicher gedacht ist, bei dem es sich um eine nicht relationale Dokumentendatenbank handelt. Das Beispiel stammt von EF-Programm-Manager Rowan Miller unter github.com/rowanmiller/Demo-EF7. Beachten Sie, dass das Beispiel mit der Version 11514 der nächtlichen Alpha-Builds von EF7 ausgeführt wird.

Abbildung 1 Ein für die Arbeit mit Azure-Tabellenspeicher definierter DbContext

public class WarrantyContext : DbContext
{
  public DbSet<WarrantyInfo> Warranties { get; set; }
  protected override void OnConfiguring(DbContextOptions options) {
    var connection =
      ConfigurationManager.ConnectionStrings["WarrantyConnection"]
                        .ConnectionString;
    options.UseAzureTableStorage(connection);
  }
  protected override void OnModelCreating(ModelBuilder builder) {
    builder.Entity<WarrantyInfo>()
           .ForAzureTableStorage()
           .PartitionAndRowKey(w => w.BikeModelNo, w => w.BikeSerialNo);
  }
}

Die OnConfiguring-Methode ist neu. Sie stellt eine Möglichkeit dar, um die Art zu beeinflussen, in der EF den DbContext zur Laufzeit konfiguriert – in etwa so, wie Sie es heute schon mit der DbConfiguration-Klasse erzielen können. Beachten Sie die "builder.UseAzureTableStorage"-Erweiterungsmethode, die vorhanden ist, weil ich ebenfalls das "EntityFramework.AzureTableStorage"-Paket in meinem Projekt installiert habe.

EF7 verwendet dieses Muster für seine verschiedenen Anbieter. Im Folgenden sehen Sie eine OnConfiguring-Methode in einer DbContext-Klasse in einem für SQLite gedachten Projekt:

protected override void OnConfiguring(DbContextOptions builder) {
  string dir = ApplicationData.Current.LocalFolder.Path;
  string connection = "Filename=" + Path.Combine(dir, "VermontBrewery.db");
  builder.UseSQLite(connection);
}

In diesem Projekt ist das "EntityFramework.SQLite"-Paket installiert, sodass mir nun stattdessen die UseSQLite-Erweiterungsmethode zur Verfügung steht.

Weiter oben in der WarrantyContext-Klasse in Abbildung 1 können Sie die vertraute OnModelCreating-Außerkraftsetzung, in der ich einige spezielle Zuordnungen vornehme. Wiederum werden mir aus dem NuGet-Paket "EntityFramework.AzureTableStorage" Methoden bereitgestellt. Ich wähle die gewünschten Pakete auf Grundlage der von mir benötigten Funktionen aus. Azure-Tabellenspeicher verwendet für die eindeutige Identität sowie zur Unterstützung der Tabellenpartitionierung ein Schlüssel/Wert-Paar. Um Daten abzurufen oder zu speichern, ist es kritisch zu wissen, welche Werte für den PartitionKey und den RowKey verwendet werden, damit die API eine Methode bereitstellt – PartitionAndRowKey– die es Ihnen erlaubt, die Eigenschaften zu den geeigneten Schlüsseln zuzuordnen. Das Konzept unterscheidet sich nicht von der Art, in der Sie die Fluent API oder Datenanmerkungen verwenden konnten, um die Eigenschaft anzugeben, die dem primären Schlüssel einer relationalen Datenbank zugeordnet wird.

Dank dieser Zuordnung kann ich eine vertraute LINQ-Abfrage schreiben, um einige Daten abzurufen:

var warranty = _context.Warranties
          .Where(w =>
            w.BikeModelNo == modelNo
            && w.BikeSerialNo == serialNo)
          .SingleOrDefault();

Auf diese Weise sehen Sie eine typische LINQ-Abfrage, die aber gegen den Datenspeicher des Azure-Tabellenspeichers ausgeführt wird, genauso, wie Sie es heutzutage mit einer relationalen Datenbank machen können.

Dieselbe Demo aktualisiert auch warranty-Objekte, erstellt mithilfe von DbSet.Add neue und fügt diese ein und verwendet DbContext.SaveChanges, um wieder alles dauerhaft im Datenspeicher zu speichern, genau, wie es heute mit EF6 und schon immer, seit es EF gibt, gemacht wird.

Interessant ist darüber hinaus, wie Entity Framework schon immer eine Gruppe kanonischer Funktionen zum Zuordnen zu relationalen Datenbanken unterstützt hat, es aber den Datenbankanbietern überlassen hat festzulegen, wie diese in die Zieldatenbank zu übersetzen sind. EF7 wird über eine Gruppe kanonischer Funktionen auf hoher Ebene verfügen, die sowohl von relationalen als auch von nicht relationalen Datenspeichern interpretiert werden können. Es wird auch eine Gruppe von Funktionen auf niedrigerer Ebene geben, die sich auf relationale Datenbanken konzentrieren und in der "EntityFramework.Relational"-Assembly gekapselt sind. Alle Anbieter relationaler Datenbanken sind davon abhängig, und – genau wie heute – wird ihre spezifische Verarbeitung von Datenbankinteraktionen in ihren eigenen Anbieter-APIs enthalten sein, wie das von mir zuvor verwendete EntityFramework.SQLite. Sie werden Erweiterungsmethoden in den Anbietern finden, die von einer AsRelational-Methode hervorgebracht werden, die in der Relational-API enthalten ist. Es ist eine Erweiterungsmethode von DbContext.

Es gibt sogar einen speicherinternen Datenspeicheranbieter, der für Komponententests gedacht ist, wenn Sie eine Datenbankinteraktion vermeiden möchten, die möglicherweise an der zu testenden Logik beteiligt ist. Typischerweise verwenden Sie in solchen Szenarios Fakes oder Mockingframeworks, um die Datenbankinteraktion nachzubilden.

Wenn Sie beispielsweise einen Test einrichten, um eine Abfrage oder Aktualisierung der Datenbank durchzuführen, hätten Sie in etwa Code wie den folgenden, um die Datenbank zu instanziieren:

using (var context = new BreweryContext()) {
  // Perform some action against the context
}

Sie können unkompliziert zu einem speicherinternen Speicher wechseln, indem Sie zuerst das "entityframework.InMemory"-Paket in Ihrem Testprojekt installieren, einen DbContextOption für InMemoryStore definieren und dann angeben, dass der Kontext diese Option verwenden soll. Auch hier ist dies wiederum dank der Erweiterungsmethoden möglich, die von dieser API bereitgestellt werden:

var options = new DbContextOptions().UseInMemoryStore();
using (var context = new BreweryContext(options)){
  // Perform some action against the context
}

Mehr Funktionen, mehr Möglichkeiten, viel mehr Flexibilität

Sie können bereits die Vorteile der neuen Codebasis an der Flexibilität erkennen, die die Erweiterungsmethoden bereitstellen, sowie an der Möglichkeit, die Entity Framework-Pipeline mithilfe der OnConfiguring-Überladung zu beeinflussen. In der gesamten neuen Codebasis gibt es Erweiterungspunkte, nicht nur zum Ändern von EF7, sondern auch um es Ihnen leichter zu machen, Ihre eigene Logik in EF7 zu integrieren.

Die neue Kerncodebasis gibt dem EF-Team eine Möglichkeit, einige schon sehr alte Probleme zu beheben. Beispielsweise besitzt die Version, die ich verwende, bereits Unterstützung für Batchaktualisierungen, was bei relationalen Datenbanken der Standard ist. Ich habe mit Code herumgespielt, der es mir ermöglicht, meine eigenen Methoden inline in LINQ-Abfragen zu verwenden, ohne die gefürchtete Meldung "Entity Framework kann diese Methode nicht in SQL übersetzen." zu erhalten. Stattdessen sind EF und die Anbieter in der Lage, zu analysieren, welcher Teil der Abfrage in SQL umgesetzt, und welcher Teil lokal auf dem Client ausgeführt wird. Ich bin mir sicher, dass es für diese spezifische Funktion Schutz vor einigen potenziellen Leistungsproblemen sowie eine Anleitung zu deren Vermeidung geben wird.

Das Team konnte die lange geforderte "Unique Foreign Keys"-Funktion für Modelle hinzufügen. Sie untersuchen ebenfalls genau, ob sie Unterstützung für Tabellenwertfunktionen sowie übersichtlichere Verfahren zur Handhabung unverbundener Daten bereitstellen können, was ein Aspekt ist, auf den ich mich schon seit Jahren mit Entity Framework konzentriere. Es ist ein gängiges Problem bei nicht verbundenen Anwendungen, nicht nur wenn Entity Framework daran beteiligt ist, und es lassen sich nicht einfach Algorithmen erstellen, die konsistent in allen Szenarios funktionieren. Ein neuer Ansatz ist also definitiv erforderlich.

Es gibt noch viele weitere, faszinierende neue Funktionen in EF7. Ich kann Ihnen nur wärmstens empfehlen, einen längeren Blick in die Beiträge im ADO.NET-Teamblog unter blogs.msdn.com/adonet zu werfen. Zusätzlich zu dem Beitrag, auf den ich weiter oben verlinkt habe, hat Rowan Miller ausführlich über die Entscheidung geschrieben, die Designer-Unterstützung in EF7 fallen zu lassen. Siehe hierzu "EF7 – What Does 'Code First Only' Really Mean" unter bit.ly/1sLM3Ur. Lesen Sie diesen Blog regelmäßig, und bleiben Sie auch beim GitHub-Projekt auf dem Laufenden. Das Wiki zu GitHub (bit.ly/1viwqXu) enthält Links zu Informationen darüber, wie Sie auf die nächtlichen Builds zugreifen können, wie Sie den Quellcode herunterladen, kompilieren und debuggen können sowie einige exemplarische Vorgehensweisen und die Mitschriften der Design-Besprechungen. Das Team ist sehr an Ihrem Feedback interessiert und freut sich über Pull-Anforderungen von Ihnen.

Keine leichte Entscheidung

Mir ist sehr daran gelegen, über EF7 zu schreiben, um dabei zu helfen, einige Befürchtungen wegen solch umwälzender Änderungen zu beschwichtigen und die Angst, dass einige der bestehenden EF-Funktionen, die von zentraler Bedeutung für Ihre Anwendungen sind, es nicht in EF7 schaffen könnten, zu zerstreuen. Solche Ängste sind nicht unbegründet, und weder das Team noch ich nehmen sie auf die leichte Schulter. Doch das Verständnis, dass EF6 nicht verschwinden, sondern sich sogar noch durch Beiträge aus der Community weiter entwickeln wird, ist von zentraler Bedeutung. Wenn Sie von der Weiterentwicklung profitieren möchten, müssen Sie einige schwere Entscheidungen treffen. Ein Upgrade großer Anwendungen wird nicht leicht werden, und Sie sollten Ihre Optionen sorgfältig abwägen. Vielleicht können Sie Ihre Anwendung ja aufteilen und nur einige kleinere Teile umschreiben, um von EF7 zu profitieren.

Ich möchte es noch mal betonen. Während ich diese Kolumne schreibe, befindet sich EF7 immer noch in einem sehr frühen Stadium, und ich bin nicht sicher, wie weit es sein wird, wenn Sie diese Zeilen lesen. Aber die aktuell verfügbare Quellcode- und NuGet-Pakete stehen bereit, um sie zu untersuchen, mit ihnen zu experimentieren und Feedback zu geben. Bedenken Sie, dass das Team möglicherweise nicht immer alle Anbieter-APIs (wie Redis, SQLite und andere) parallel zur Weiterentwicklung der Haupt-API auf dem neuesten Stand hält. Gemäß dem Beitrag unter bit.ly/1ykagF0, "EF7 – Priorities, Focus and Initial Release“, wird sich die erste Version von EF7 auf Kompatibilität mit ASP.NET 5 konzentrieren. In den Folgeversionen wird der Funktionsumfang erweitert. Dennoch, auch wenn EF7 noch nicht stabil genug ist, um damit mit dem Erstellen von Anwendungen zu beginnen, gibt es definitiv genug, womit man schon einmal vorausplanen kann.

Julie Lerman ist Microsoft MVP, .NET-Mentor 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“ (2010) sowie der Ausgaben „Code First“ (2011) und „DbContext“ (2012). Alle Ausgaben sind im Verlag O’Reilly Media erschienen. Folgen Sie ihr auf Twitter unter twitter.com/julielerman, und besuchen Sie ihre Pluralsight-Kurse unter juliel.me/PS-Videos.

Unser Dank gilt dem folgenden technischen Experten von Microsoft für die Durchsicht dieses Artikels: Rowan Miller

Dieser Artikel basiert auf einer Alphaversion von Entity Framework 7. Änderungen an allen Informationen sind vorbehalten.