Ausblick auf Entity Framework 7

Frühjahrsputz für Entitäten
Kommentare

Entity Framework 7 trennt sich von Altlasten und Mehrgleisigkeiten, die sich im Laufe der letzten Jahre angesammelt haben. Als neues schlankes Framework wird es für .NET Core und somit auch für WinRT zur Verfügung stehen und auch den Zugriff auf NoSQL-Datenbanken erlauben.

Mit .NET Core wird Microsoft eine schlanke, modulare und plattformunabhängige Variante von .NET anbieten. Dies nimmt das nun für ASP.NET und das Entity Framework verantwortliche Produktteam zum Anlass, einen Frühjahresputz durchzuführen. Wie ASP.NET 5 auch, stellt Entity Framework 7 eine Neuentwicklung dar. Altlasten werden dabei ebenso wie Mehrgleisigkeiten abgestoßen und das Fundament wird erweitert, um die Reichweite des Frameworks zu erhöhen. Da das Entity Framework 7 für .NET Core entwickelt wurde, wird es auch für klassische .NET-Anwendungen sowie für WinRT-Anwendungen zur Verfügung stehen. Darüber hinaus wird es neben relationalen Datenbanken auch NoSQL-Datenbanken unterstützen.

Entity Framework heute

Die aktuelle Version des Entity Frameworks ist ein klassischer O/R Mapper, der Elemente aus der objektorientierten Welt, beispielsweise Klassen, auf ihre Gegenstücke in der relationalen Welt abbildet, beispielsweise auf Tabellen. Um diese Abbildung durchführen zu können, stützt sich Entity Framework auf ein so genanntes Entity Data Model. Dieses beschreibt das Objektmodell, das Datenbankschema und welche Elemente im Objektmodell welchen Elementen im Datenbankschema entsprechen.

Das Entity Data Model liegt entweder explizit in Form einer XML-Datei vor oder wird zur Laufzeit aus Entitätsklassen und Konfigurationscode abgeleitet. In beiden Fällen kann der Entwickler mit dem Modellieren des Objektmodells beginnen. Alternativ dazu kann er auch mittels Reverse-Engineering aus einer bestehenden Datenbank ein explizites Entity Data Model oder Entitätsklassen inkl. Konfigurationscode generieren lassen.

Durch die Abstraktion des Datenbankzugriffs gestaltet sich der entwickelte Datenzugriffscode selbsterklärend und der Entwickler muss sich nicht selbst um den monotonen sowie fehleranfälligen Brückenschlag zwischen der objektorientierten und der relationalen Welt kümmern. Darüber hinaus kann der Entwickler zwischen unterschiedlichen relationalen Datenbanken wechseln.

In den Genuss des Entity Frameworks kommt der Entwickler lediglich beim Einsatz des klassischen .NET Frameworks. Unter WinRT bleibt ihm das moderne Datenzugriffsframework aus Redmond verwehrt. Eine weitere Einschränkung stellt der Fokus auf relationale Datenbanken dar. Obwohl es sich dabei um das mit Abstand am häufigsten eingesetzte Paradigma in der Datenbankwelt handelt, sind alternative Ansätze (Stichwort NoSQL) derzeit äußerst aufstrebend – nicht zuletzt, weil sie im Hinblick auf die Skalierbarkeit einige Vorteile versprechen.

Ziele für Version 7

Im Zuge der Entwicklung des neuen schlanken und modularen .NET Core stellt Microsoft auch ein neues Entity Framework bereit – trotz der Versionsnummer 7 eine Neuentwicklung. Mit ihr möchte das Produktteam (genauso wie mit ASP.NET 5) aufräumen sowie Einschränkungen beseitigen, die im Fundament des Frameworks begraben liegen.

Im Zuge des Aufräumens trennt sich Microsoft sowohl vom älteren ObjectContext-basierten Programmiermodell als auch vom Einsatz eines expliziten Entity Data Models, das in Form einer XML-Datei vorliegt. Während der ObjectContext ursprünglich bis Version 4 die zentrale Klasse beim Einsatz von Entity Framework war, kommt seit Visual Studio 2012 standardmäßig der leichtgewichtigere DbContext, gemeinsam mit Code First eingeführt, zum Einsatz. Genaugenommen ist dieser zwar bis inklusive Version 6 lediglich ein Wrapper für den ObjectContext, letzteren nimmt der Entwickler jedoch so gut wie nicht wahr. Aus diesem Grund dürften ihn auch nur die wenigsten vermissen.

Um Mehrgleisigkeiten zwischen den einzelnen Spielarten zu verhindern, steht in Zukunft nur mehr die Variante Code First zur Verfügung. Dabei handelt es sich ohnehin um die von vielen Seiten bevorzugte Einsatzart des Entity Frameworks – zumal eine codebasierte Konfiguration nicht nur vor dem Hintergrund der Quellcodeverwaltung einfacher handzuhaben ist, sondern Entwicklern häufiger auch intuitiver erscheint als eine Konfiguration über einen grafischen Designer oder einer XML-Datei. Darüber hinaus bietet Code First mittels Migrations auch eine äußerst mächtige Möglichkeit zur Aktualisierung bestehender Datenbanken und der Entwickler erhält mehr Freiheiten bei der Gestaltung und Verteilung einzelner Entitäten. Wie eingangs erwähnt, schließt die Spielart Code First ein Reverse-Engineering aus einer bestehenden Datenbank nicht aus. Somit hat der Entwickler auch künftig die Möglichkeit, entweder mit einem Objektmodell oder mit dem Datenbankdesign zu starten. Für letzteren Ansatz möchte das Produktteam Werkzeuge zur Verfügung stellen.

Da das Entity Framework 7 für .NET Core entwickelt wird, auf dem künftig auch WinRT basieren wird, kann es auch bei Windows-(Phone-)8+-Apps zum lokalen Vorhalten von Daten eingesetzt werden. Diese Option unterstreichen die Entwickler aus Redmond, indem sie den Einsatz von SQLight unterstützen.

Die Reichweite des Entity Frameworks soll jedoch nicht nur im Hinblick auf die Plattformen erweitert werden, auf denen es genutzt werden kann, sondern auch im Hinblick auf die Datenbanken, die der Entwickler damit adressieren kann. Aus diesem Grund wird Entity Framework 7 zusätzlich NoSQL-Datenbanken unterstützen. In der aktuellen Beta findet man z. B. Unterstützung für den Azure Table Store sowie für die Key-Value-Datenbank Redis. Das Produktteam betont an dieser Stelle, dass es nicht das Ziel sein soll, die Unterschiede zwischen relationalen Datenbanken und NoSQL-Datenbanken durch eine Abstraktion zu verbergen. Beim Einsatz von Datenbanken, die z. B. keine Beziehungen unterstützen, wird der Entwickler somit auch nicht in der Lage sein, Beziehungen via Entity Framework zu nutzen. Der Vorteil beschränkt sich somit auf die Möglichkeit, für verschiedene Datenbankparadigmen ein einziges API zu nutzen.

All diese Neuerungen können natürlich nicht ohne Breaking Changes umgesetzt werden, darauf weist das Produktteam explizit hin. Allerdings möchte man das API aus Entwicklersicht soweit sinnvoll beibehalten, damit diese weiterhin auf ihr bestehendes Know-how setzen können. Realistischerweise wird eine Portierung jedoch nicht ohne Codeanpassungen möglich sein. Wem dies nicht möglich ist, kann man analog zu ASP.NET 4.x und dem neuen 5.x weiterhin die bestehende Version 6.x von Entity Framework nutzen oder erst zu einem späteren Zeitpunkt portieren.

Entity Framework 7 einbinden und konfigurieren

Zum Testen der aktuellen Beta von Entity Framework 7 empfiehlt sich der Einsatz einer Anwendung, die sich auf .NET Core abstützt. Dies ist zum Beispiel bei ASP.NET-5-Anwendungen der Fall, die man mit der Visual Studio 2015 CTP erstellen kann. Für den Einsatz von Entity Framework benötigt der Entwickler die NuGet-Pakete EntityFramework.Commands sowie ein weiteres Paket, das den Zugriff auf die gewünschte Datenbank implementiert. Handelt es sich bei der Datenbank der Wahl beispielsweise um SQL Server, bindet der Entwickler zusätzlich das Paket EntityFramework.SqlServer ein. Diese Pakete referenzieren weitere NuGet-Pakete, die der Entwickler zum Einsatz von Entity Framework benötigt. Um beispielsweise Migrations nutzen zu können, richtet der Entwickler darüber hinaus auch ein Kommando ein, das er über die Kommandozeile aufrufen kann und das sich auf EntityFramework.Commands abstützt. Listing 1, das einen Auszug aus einer project.json beinhaltet, demonstriert dies. Es legt fest, dass EntityFramework.Commands sowie die Unterstützung für einige verschiedene Datenbanken in das Projekt einzubinden sind und definiert ein Kommando ef, das über die Kommandozeile aufgerufen werden kann.

[...]
"dependencies": {
  "EntityFramework.Commands": "7.0.0-beta1",
  "EntityFramework.SQLite": "7.0.0-beta1",
  "EntityFramework.SqlServer": "7.0.0-beta1",
  "EntityFramework.InMemory": "7.0.0-beta1"
}, 
"commands": {
  "run": "run",
  "ef": "EntityFramework.Commands"
},
[...]

Die Erstellung der Entitäten (Listing 2) sowie des DbContext-Derivats (Listing 3) gestaltet sich ähnlich wie in vorherigen Versionen von Entity Framework. Bei einer genaueren Betrachtung von Listing 3 fallen jedoch ein paar Unterschiede zu Version 6.x auf. Beispielsweise zeigt es, dass der Entwickler den Context nun über ein Objekt des Typs DbContextOptions konfiguriert. Dazu überschreibt er entweder OnConfiguring oder übergibt die zu nutzende DbContextOptions-Instanz an den Konstruktor. Letztere Option bietet sich beim Einsatz von Dependency Injection (DI) an, da in diesem Fall beim Start der Anwendung ein konfiguriertes DbContextOptions-Objekt beim DI-Container registriert werden kann.

public class Hotel
{
  public Hotel() { Buchungen = new List(); }
  public int HotelId { get; set; }
  public string Name { get; set; }
  public int Sterne { get; set; }
  public virtual List Buchungen { get; set; }
}

public class Buchung
{
  public int BuchungId { get; set; }
  public int HotelId { get; set; }
  public string Vorname { get; set; }
  public string Nachname { get; set; }
  public virtual Hotel Hotel { get; set; }
}
public class HotelDbContext : DbContext
{
  public HotelDbContext() { }
  public HotelDbContext(DbContextOptions options) : base(options) { }

  public DbSet Hotels { get; set; }
  public DbSet Buchungen { get; set; }

  protected override void OnConfiguring(DbContextOptions options)
  {
    options.UseSqlServer(@"Data Source=[…];MultipleActiveResultSets=True");
  }

  protected override void OnModelCreating(ModelBuilder modelBuilder)
  {
    modelBuilder
    .Entity()
    .OneToMany(h => h.Buchungen, b => b.Hotel)
    .ForeignKey(b => b.HotelId)
    .Required();

    modelBuilder.Entity().Key(p => p.HotelId);
    modelBuilder.Entity().Key(b => b.BuchungId);

    // modelBuilder.Entity()
    // .Property(p => p.Name).ForRelational().Column("HotelName");

    // modelBuilder.Entity()
    // .Property(p => p.BuchungId).ForSqlServer().UseIdentity();
  }
}

Dem DbContextOptions-Objekt teilt der Entwickler mit, welche Datenquelle er verwenden möchte. Im betrachteten Beispiel kommt durch Aufruf der Methode UseSqlServer SQL Server zum Einsatz. Diese Methode nimmt die zu verwendende Datenbankverbindungszeichenfolge entgegen. Wichtig ist dabei, dass der Entwickler die Option MultipleActiveResultSets (MARS) aktiviert – zumal die aktuelle Implementierung nicht in der Lage ist, die benötigten Abfragen sequenziell abzuarbeiten, sondern gleichzeitig mehrere Abfragen verwendet.

Ein weiterer Unterschied fällt bei der Definition von Beziehungen auf. Im Gegensatz zur Version 6 werden diese nun prägnant durch einen einzigen Methodenaufruf bekanntgegeben. Die betroffene Methode nimmt im Fall unidirektionaler Beziehungen einen Lambda-Ausdruck sowie im Fall von bidirektionalen Beziehungen zwei davon entgegen. Mit diesen legt der Entwickler fest, über welche Navigationseigenschaft er zur anderen Seite der Beziehung navigieren möchte bzw. über welche der Rückweg erfolgt. Das betrachtete Beispiel demonstriert dies unter Verwendung der Methode OneToMany, mit der es auf die 1:N-Beziehung zwischen Hotel und Buchung hinweist.

Einen weiteren Unterschied bei der Konfiguration des Kontexts deuten die beiden auskommentierten Anweisungen am Ende der Methode OnModelCreating an. Erstere legt den Namen der Spalte fest, auf die die Eigenschaft Name abzubilden ist; Letztere aktiviert den Einsatz von Identitätsspalten. Die dazu zur Verfügung stehenden Methoden stehen im Gegensatz zu Entity Framework 6.x nicht mehr direkt, sondern nur mehr über eine Indirektion zur Verfügung. Diese wird durch Methoden dargestellt, die der Namenskonvention „ForXYZ“ entsprechen. Im ersten Fall kommt hierzu die Methode ForRelational zum Einsatz, im zweiten hingegen ForSqlServer. Diese Indirektion ist der Tatsache geschuldet, dass Entity Framework künftig mit verschiedenen Datenbankparadigmen einsetzbar sein soll. Da Spalten nicht in allen Datenbanken zum Einsatz kommen, ist die Möglichkeit der Bezugnahme auf Spalten nicht direkt im API verankert, sondern wird u. a. über die Erweiterungsmethode ForRelational zur Verfügung gestellt. Diese Methode liefert ein Objekt, über das der Entwickler auf Spezifika relationaler Datenbanken eingehen kann. Ähnlich gestaltet es sich beim Einsatz von Identitätsspalten, die auch nicht von allen Datenbanken unterstützt werden, sich jedoch u. a. in SQL Server wiederfinden.

Diese beiden Anweisungen wurden auskommentiert, da die aktuell vorliegende Beta das Festlegen von Spaltennamen durch Migrations nicht unterstützt und Primärschlüssel, die sich auf den Typ int abstützen, beim Einsatz von SQL Server standardmäßig als Identitätsspalten einrichtet.

Datenbanken mit Migrations erstellen und aktualisieren

Der mit Entity Framework 4.3 eingeführte Mechanismus, der Migrations zum Erstellen und Aktualisieren von Datenbanken auf Basis eines Abgleichs zwischen Code und Datenbankschema erlaubt, findet sich auch in Version 7 wieder. Hat der Entwickler (wie in Listing 1 gezeigt) ein Kommando konfiguriert, das sich auf das Paket EntityFramework.Commands abstützt, kann er auf der Kommandozeile unter Verwendung des Programms k Migrations nutzen. Bei k handelt es sich um eine Laufzeitumgebung für .NET Core. Informationen zur Installation von k finden Sie hier.

Ein Aufruf von k ef im Projektverzeichnis stößt das konfigurierte und über EntityFramework.Commands bereitgestellte Kommando an. Dabei handelt es sich um eine Übersicht der möglichen Optionen, wobei die wohl wichtigste darunter die Nutzung von Migrations ist. Ein Aufruf von k ef migration bringt Migrations zur Ausführung. In diesem Fall erhält der Entwickler eine Übersicht über die Möglichkeiten der Migrations (Abb. 1). Ergänzt der Entwickler den zuvor beschriebenen Befehl, sodass sich k ef migration add v0 ergibt, erzeugt Migrations im Projektverzeichnis ein Migrationsskript zum Erzeugen bzw. Aktualisieren der zugrunde liegenden Datenbank. Dieses Migrationsskript, das in diesem Fall den Namen v0 trägt, liegt – wie bei Migrations üblich – in Form einer Klasse vor und kann entweder auf der Kommandozeile oder programmatisch auf die Datenbank angewendet werden. Zur Ausführung des Migrationsskripts über die Kommandozeile setzt der Entwickler die Anweisung k ef migration apply ab; die Anweisung k ef migration script liefert hingegen ein SQL-Skript für die Migration.

Abb. 1: Nutzung von Migrations auf der Kommandozeile

Abb. 1: Nutzung von Migrations auf der Kommandozeile

 

Mit Entity Framework auf Datenbanken zugreifen

Auch beim Zugriff auf Datenbanken mit Entity Framework 7 gibt es auf den ersten Blick nur wenige Unterschiede gegenüber früheren Versionen. Listing 4 veranschaulicht dies: Zunächst instanziiert es einen DbContext, anschließend erzeugt es zu speichernde Objekte und fügt diese zum Kontext hinzu. Für den Abgleich mit der Datenbank ruft es SaveChanges auf. Ein erneuter Aufruf von SaveChanges überträgt eventuelle Änderungen an den Objekten in die Datenbank. Anschließend verwendet das betrachtete Listing eine LINQ-Abfrage, um die zuvor gespeicherten Daten wieder zu laden. Diese lädt mittels Eager Loading sämtliche Hotels inkl. Buchungen.

using (var ctx = new HotelDbContext())
{
  ctx.Database.EnsureDeleted();
  // ctx.Database.EnsureCreated();
  ctx.Database.AsRelational().ApplyMigrations();

  Console.WriteLine("--- Objekte einfügen ---");
  var hotel = new Hotel() { […] };
  var buchung1 = new Buchung { […] };
  var buchung2 = new Buchung { […] };
  hotel.Buchungen.Add(buchung1);
  hotel.Buchungen.Add(buchung2);
  ctx.Hotels.Add(hotel);
  ctx.Buchungen.Add(buchung1);
  ctx.Buchungen.Add(buchung2);
  ctx.SaveChanges();

  Console.WriteLine("--- Aktualisieren ---");
  hotel.Sterne++;
  buchung1.Nachname = "Mustermann";
  ctx.SaveChanges();

  Console.WriteLine("--- Ausgabe ---");
  var hotels = ctx.Hotels.Include(h => h.Buchungen).ToList();
  foreach (var h in hotels)
  {
    Console.WriteLine(h.Name + " " + h.Sterne);
    foreach (var b in h.Buchungen)
    {
      Console.WriteLine("t" + b.Vorname + " " + b.Nachname);
    }
    Console.WriteLine();
  }
}

Ein auffälliger Unterschied sind die Methoden EnsureDeleted, EnsureCreated und ApplyMigrations, auf die das Listing am Anfang Bezug nimmt. Diese Methoden löschen die zugrunde liegende Datenbank, erzeugen sie bzw. erzeugen sie mittels Migrations inkl. des benötigten Schemas. Da sich das bloße Erzeugen und das Erzeugen mittels Migrations gegenseitig ausschließen, wurde EnsureCreated im betrachteten Fall auskommentiert.

Ein weiterer Unterschied ist die Tatsache, dass die beiden Buchungen mit der Methode ctx.Buchungen.Add explizit zum Kontext hinzugefügt werden. In Entity Framework 6.x und davor hätte es gereicht, lediglich das Hotel, das ohnehin auf die Buchungen verweist, zum Kontext hinzuzufügen. Ob dies so bleibt oder ob das Produktteam diese Funktion erst noch zu implementieren hat, wird die Zeit zeigen.

Neben den hier besprochenen Änderungen weist die aktuelle Beta noch einige Einschränkungen auf: Lazy Loading, getrennte Objekte via Attach und komplexe Typen werden noch nicht unterstützt. Es ist davon auszugehen, dass das Produktteam zumindest die ersten beiden dieser drei Einschränkungen bis zur Fertigstellung von Version 7 oder mit einer darauffolgenden Minor-Version beseitigt.

Unterstützung für andere Datenbanken

Neben SQL Server unterstützt die aktuelle Beta von Entity Framework 7 noch andere Datenquellen. Dazu gehört eine einfache In-Memory-Datenquelle, die sich für Testzwecke anbietet und beim DbContextOptions-Objekt mit der Methode UseInMemoryStore(true) eingerichtet werden kann. Der zu übergebene Boolean gibt darüber Auskunft, ob die gespeicherten Objekte lokal für den jeweils verwendeten Kontext (false) oder global für sämtliche Kontexte der Anwendung im Hauptspeicher zu hinterlegen sind (true).

Um hingegen SQLight (siehe gleichnamiger Kasten) zu nutzen, ruft der Entwickler beim verwendeten DbContextOptions-Objekt die Methode UseSqlite auf und übergibt dabei die zu nutzende Verbindungszeichenfolge:

options.UseSqlite("Filename=test.db");
SQLight Die Version 7.0.0-beta2-11707 von Entity Framework 7 (zum Verfassungszeitpunkt dieses Artikels die aktuellste Version) weist im Hinblick auf ihre SQLight-Unterstützung bei Weitem nicht die Qualität der SQL-Server-Unterstützung auf. Beispielsweise unterstützt sie keine von der Datenbank generierten Autowerte, und Migrations stoßen bei Beziehungen zwischen Tabellen auf Probleme.

Um den Einsatz von Microsofts hochskalierbaren Datenspeicher Azure Table Storage zu konfigurieren, verwendet der Entwickler die Methode UseAzureTableStorage, die Eckdaten für die Verbindung mit der gewünschten Table-Storage-Instanz entgegennimmt. Da Table Storage keine Beziehungen zwischen Einträgen unterstützt, kann der Entwickler auch mit Entity Framework keine Objektbeziehungen modellieren. Versucht er es dennoch, mahnt ihn Entity Framework mit einer Exception ab. Eine Besonderheit des Azure Table Storage ist die Tatsache, dass jede Tabelle einen so genannten PartitionKey, einen RowKey und einen Zeitstempel aufweist. Die ersten beiden bilden gemeinsam den Primärschlüssel, wobei der PartitionKey für die Verteilung der Einträge auf verschiedene Partitionen genutzt wird. Die Regel dazu lautet, dass Azure alle Einträge mit demselben PartitionKey in derselben Partition und somit auf demselben Rechner platziert. Der Zeitstempel wird zur Erkennung von Konflikten herangezogen. Im Rahmen der Konfiguration muss der Entwickler zumindest die beiden Schlüssel auf Eigenschaften der jeweiligen Entitätsklassen abbilden. Dies kann er wie folgt bewerkstelligen:

modelBuilder.Entity().ForAzureTableStorage()
            .PartitionAndRowKey(x => x.HotelId, x => x.BuchungId);

Neben der Methode PartitionAndRowKey kann der Entwickler auch auf eine Methode Timestamp zurückgreifen, mit der er den Zeitstempel auf eine Eigenschaft abbildet.

Künftig wird es im Lieferumfang von Entity Framework 7 auch eine Unterstützung für die Key-Value-Datenbank Redis geben. Details zur Nutzung dieser Möglichkeit lagen zum Verfassungszeitpunkt dieses Artikels leider noch nicht vor.

Fazit

Nach rund sechs Jahren erhält Entity Framework eine erste Generealüberholung. Auch wenn es schmerzt, ein sechs Jahre altes Framework als Legacy-Technologie ansehen zu müssen, erscheint der Zeitpunkt passend – zumal .NET Core ohnehin einen Neustart darstellt.

Bei der Neuentwicklung berücksichtigt Microsoft die Erfahrungswerte der letzten Jahre und fokussiert sich auf die Spielart Code First, die die Versprechen der beiden anderen Spielarten – Database First und Model First – besser als diese selbst hält. Zum einen erlaubt Code First ein Reverse-Engineering aus bestehenden Datenbanken, und zum anderen ist diese jüngste Spielart in der Lage, aus einem Objektmodell eine Datenbank zu generieren, sowie – was noch wichtiger ist – bestehende Datenbanken zu aktualisieren. Letzteres war bei Model First nicht möglich, wenn man mal von einer Visual-Studio-Erweiterung absieht, die es nur für Version 2010 gab. Auch die Arbeit mit dem nicht immer handsamen Entity-Data-Model-Designer entfällt auf diese Weise, und Entwickler bekommen mehr Kontrolle über die generierten oder selbst erstellten Entitätsklassen. Dazu kommt, dass Konkurrenzprodukte wie NHibernate von Anbeginn an erfolgreich auf eine analoge Vorgehensweise setzen.

Auch die Tatsache, dass die Reichweite von Entity Framework im Hinblick auf die unterstützten Plattformen und Datenbanken erhöht wird, ist erfreulich. So wird dem Entwickler künftig ein einziges API zur Verfügung stehen, um verschiedenste Datenbankparadigmen zu bedienen. Ob dies zweckmäßig ist, wird die Zukunft zeigen. Ein wenig Skepsis ist an dieser Stelle durchaus angebracht, zumal WCF – im Nachhinein betrachtet nur bedingt erfolgreich – in den letzten Jahren einen ähnlichen Ansatz im Hinblick auf verschiedene Servicetechnologien verfolgt hat. Durch die Abstraktion verschiedener Ansätze landete man schlussendlich irgendwo zwischen dem kleinsten gemeinsamen Nenner und einem Framework mit Funktionen, die zur Laufzeit nur funktionieren, wenn die zugrunde liegende Technologie sie auch unterstützt. Ersteres schränkt ein, Letzteres führt zu Verwirrung und erhöht die Komplexität. Positiv ist an dieser Stelle jedoch zu unterstreichen, dass das Produktteam hinter Entity Framework 7 ganz offen anspricht, dass es nicht anstrebt, die Unterschiede zwischen den einzelnen Datenbankparadigmen durch eine Abstraktion vor dem Entwickler zu verbergen. Somit entstehen diesbezüglich, anders als damals bei WCF, weniger falsche Erwartungshaltungen bei den Entwicklern.

Aufmacherbild: Staub-Häschen von Shutterstock.com / Urheberrecht: Suzanne Tucker

Unsere Redaktion empfiehlt:

Relevante Beiträge

Meinungen zu diesem Beitrag

X
- Gib Deinen Standort ein -
- or -