Diese Darstellungsform bietet einige Vorteile. Ein grosses Modell kann so auf mehrere Sichten aufgeteilt werden, ohne auf dem Komfort einer Edmx-Datei verzichten zu müssen. So erspare ich mir auch das Management mehrerer Kontexte im Code, was auch zur Vereinfachung beiträgt. So habe ich beides und muss mich nicht mehr entscheiden zwischen: schöne kleine Modelle und komplexer Code oder einfacher Code dafür ein grosses unübersichtliches Modell.

Ein weiteres neues Feature ist auch die Änderung der Reihenfolge einzelner Eigenschaften einer Entität, dies wird über das Kontextmenü ermöglicht. In Verbindung mit Code-Generierung kann das sehr nützlich sein.

Aber, aktuell werden eigene Eigenschaften im Eigenschaftsfenster des EDM noch nicht unterstützt. Gerade im Zusammenhang mit dem Ansatz pragmatischer Modelle bzw. Metaprogrammierung kann dieses Feature sehr mächtig sein.

Weitere neue Funktionen der JuneCTP sind in diesem Beitrag beschrieben.

Bei Gelegenheit werde ich mich auch mit dem Enum-Support auseinander setzen. Primär werde ich dabei einen Blick auf die Worst-Case-Szenarien setzen, denen ich in Zukunft wohl auch begegnen werde.

Kurz bevor der Juli begann, wurde noch schnell die JuneCTP für das Entity Framework veröffentlicht. Da ich bisher alle Download-Links in meinen Blog hinterlegt habe und das jetzt bei der Einrichtung eines neuen VM-Image für mich sehr hilfreich war, werde ich den Link auch hinterlegen. ;-)

Details und die Downloadlinks zur EF June CTP 2011 gibt es hier.

Liebevoll wird diese CTP bereits EF Enum Edition genannt. *fg*

Eigentlich schon ein wenig unterhaltsam, da spricht man überall von Anwendungsintegration, Auswertungen, Data Mining, DWH und jetzt Enum.

Ich hoffe nur, dass diejenigen Entwickler die so lauthals den Support dafür gefordert haben, auch Verantwortungsbewusst damit umgehen werden.

Die Code First-Variante verpasst dem Entity Framework eine neue Version und wird als eigenständiges Update kommen. Ganz bewusst wird hier auf die Kombination mit dem Service Pack 1 verzichtet. Somit wird Code First noch im ersten Quartal bereitgestellt werden.

In meinen Vortrag von der VSone habe ich bereits die Pluggable Conventions verwendet, als Möglichkeit den Konfigurationsaufwand für TPT zu verringern. Diese Pluggable Conventions schaffen es nicht ins EF 4.1. Die Beispiele werden dementsprechend nicht mehr funktionieren.

Was mit dem EF 4.1 auch in DB First und Model First Einzug halten wird, ist die Validierung mit den DataAnnotations. Das finde ich sehr hilfreich, da es mir einen roten Faden im Bezug auf die Validierungsstrategie aufzeigt und unnötige Datenbankanfragen minimieren kann.

Was mit EF 4.1 Code First noch nicht unterstützt wird, sind Stored Procedures. Hier muss man sich im Hinterkopf behalten, was ich in diesem Beitrag aufgezeigt habe. Am besten zeichnet man vor Projektbeginn ein Umweltdiagramm, um alle Stakeholder ermitteln zu können. Gehört zwar zur alten Schule und macht auch fast niemand, aber es hat sich in meinen Augen bewährt.

Weitere Details gibt es im ADO.NET team blog.

Der Code First-Ansatz hat seine Reize. Mit den verbesserten Funktionalitäten, trotz kleiner Bugs, geht es auch zügig von der Hand. Mit der CTP5 hat auch eine T4 Vorlage Einzug gehalten, dass die Möglichkeit bietet, mit dem EDMX-Designer den DbContext zu nutzen. Einfach ausgedrückt ist der DbContext ein Wrapper auf den ObjectContext, der das Mapping bzw. den Umgang mit dem EDMX-File vereinfacht.

Dabei muss auch erwähnt werden, das Paradigmen, die einfach und locker von der Hand gehen, gerne verwendet werden. Die Codezentrierte Anwendungsentwicklung, als Vertreter des Top down-Ansatzes, kann aber in Konflikt mit einzelnen Stakeholdern stehen. Problematisch wird es, wenn man mit dem Top down-Ansatz begonnen hat und in einer späteren Phase Anforderungen hinzukommen, die aktuell mit der CTP5 nicht realisierbar sind. Zudem kann die Gefahr bestehen, dass die Top down Vorgehensweise zu einem Meet in the middle-Ansatz mutiert.

Ein mögliches Szenario, bei dem die Mapping-Philosophie an die Grenzen stösst, ist die Verwendung von Prozeduren und Views für die CRUD-Funktionalitäten, was mit den ObjectContext problemlos realisierbar ist. Mit Workarounds können diese Prozeduren für das Speichern, Ändern und Löschen verwendet werden, aber den Code möchte ich nicht warten.

Wenn ein CSO, Beauftragter für Datensicherheit oder ein DBA diese Anforderung in einer späteren Phase verlangt, wie es in der Realität üblich ist, stösst man mit dem Code First-Ansatz in der CTP5 sehr schnell an die Grenzen des machbaren. Aktuell ist hier das Mapping von Prozeduren oder Sichten nicht möglich und eine Variante wäre der Wechsel zum meist "unbeliebten" Bottom up. Der Vorteil für den Entwickler, es können Aufgaben an den DBA delegiert werden und die Gefahr in den Meet in the middle-Ansatz zu fallen ist ebenfalls minimiert.

Machen wir also ein kleines Beispiel, das völlig sinnfrei ist. Zuerst erstellen wir die Klassen:

Klassen (C#)
  public abstract class AbstractEntity01
  {
    public int Id { get; set; }

    [StringLength(100), Required]
    public string AbstractEntity01Field1 { get; set; }

    [StringLength(100), Required]
    public string AbstractEntity01Field2 { get; set; }
  }

  public abstract class AbstractEntity02 : AbstractEntity01
  {
    public int Id { get; set; }

    [StringLength(100), Required]
    public string AbstractEntity02Field1 { get; set; }

    [StringLength(100), Required]
    public string AbstractEntity02Field2 { get; set; }
  }

  public abstract class AbstractEntity03 : AbstractEntity02
  {
    public int Id { get; set; }

    [StringLength(100), Required]
    public string AbstractEntity03Field1 { get; set; }

    [StringLength(100), Required]
    public string AbstractEntity03Field2 { get; set; }
  }

  public abstract class AbstractEntity04 : AbstractEntity03
  {
    public int Id { get; set; }

    [StringLength(100), Required]
    public string AbstractEntity04Field1 { get; set; }

    [StringLength(100), Required]
    public string AbstractEntity04Field2 { get; set; }
  }

  public class Sample : AbstractEntity04
  {
    public int Id { get; set; }

    [StringLength(100), Required]
    public string TestField3 { get; set; }

    [StringLength(100), Required]
    public string TestField4 { get; set; }
  }

  public class Navigation01
  {
    public int Id { get; set; }
    [StringLength(100)]
    public string TestField3 { get; set; }
    [StringLength(100)]
    public string TestField4 { get; set; }
    public int SampleId { get; set; }
    public Sample Sample { get; set; }
  }

  public class Navigation02
  {
    public int Id { get; set; }
    [StringLength(100)]
    public string TestField3 { get; set; }
    [StringLength(100)]
    public string TestField4 { get; set; }
    public int SampleId { get; set; }
    public Sample Sample { get; set; }
  }

Anschliessend den DbContext:

DbContext (C#)
  public class VoelligSinnfreiContext : DbContext
  {
    public IDbSet<AbstractEntity01> AbstractEntities01 { get; set; }
    public IDbSet<Navigation01> Navigations01 { get; set; }
    public IDbSet<Navigation02> Navigations02 { get; set; }
  }

Wenn der Entwickler nun wieder die Berechtigung erhält, die Datenbank zu erstellen kommt es schon zum ersten Problem: Während der Erstellung wird dann aus der Sicht eine Tabelle. Bei dieser Vorgehensweise rutscht man also vom ursprünglich geplanten Top down-Ansatz in den Meet in the middle-Ansatz. Das Mapping der Prozeduren wird dann richtig spannend, da sich der Entwickler neben der Handarbeit des Mappings mithilfe von SqlCommand auch um die State-Aktualisierung bei Create/Update/Delete kümmern muss.

Eine andere Variante wäre jetzt der Wechsel zum Bottom up-Ansatz und die Verwendung des EDM-Designers. Dazu benötigen wir natürlich eine EDMX-Datei. Aus dem DbContext heraus kann diese wie folgt erstellt werden:

DbContext (C#)
  
  public class VoelligSinnfreiContext : DbContext
  {
    public IDbSet<AbstractEntity01> AbstractEntities01 { get; set; }
    public IDbSet<Navigation01> Navigations01 { get; set; }
    public IDbSet<Navigation02> Navigations02 { get; set; }

    protected override void OnModelCreating(System.Data.Entity.ModelConfiguration.ModelBuilder modelBuilder)
    {
      this.CreateEdmFile(modelBuilder);
      base.OnModelCreating(modelBuilder);
    }

    protected void CreateEdmFile(System.Data.Entity.ModelConfiguration.ModelBuilder model)
    {
      string path = @"Pfad";
      var edm = model.Build(new DbProviderInfo("System.Data.SqlClient", "2008"));
      using (var writer = new XmlTextWriter(Path.Combine(path, "VoelligSinnfreiContext.edmx"),
        Encoding.UTF8))
      {
        edm.WriteEdmx(new DbProviderInfo("System.Data.SqlClient", "2008"), writer);
      }
    }
  }

Die Funktionalität ist also wieder gewährleistet.

Im Bezug auf die Prozeduren, hier sind für die Zukunft bereits Anpassungen geplant. Mit dem DbContext soll es eines Tages möglich sein, diese gleich mit zu erstellen. Wann es so weit sein wird, weiss ich aber auch nicht. Wenn dieser Punkt realisiert ist, wäre der Wechsel zurück ohne Probleme möglich.

Aber auch der Ansatz mit der Erstellung des EDMX-Files hat so seine Ecken und Kanten. Dieser funktioniert nur einwandfrei, wenn man völlig auf die Konventionen setzt. Aktuell kommt es zu Ausnahmen, wenn die manuellen Mappings berücksichtigt werden sollen.

Eine andere Alternative wäre natürlich auch der Wechsel auf einen anderen O/R Mapper, wenn die nötige Zeit dafür besteht. Aber auch hier gilt: Vorsicht vor Meet in the middle!

Mit diesem Beitrag werden die Beispiele nachgeliefert. Im Zip-File befinden sich auch die Datenbankskripts, die bedingt durch die enthaltenen Testdaten etwas gross sind.

Bevor die Skripts ausgeführt werden, müssen die Datenbanken manuell angelegt werden.

Eine Warnung zum Extrem-Beispiel mit dem Span-Query, es ist definitiv nicht zur Nachahmung für produktive Projekte empfohlen, es soll nur die möglichen Workarounds mit dem Kontext-Cache aufzeigen, um das Ganze optimieren zu können. Für die Optimierung in Verbindung mit Paging war die Zeit leider zu knapp.

Materialen

• Vortrag
• Beispiele
• LinqPad (Freie Version)
• ORM Entity Framework/NHibernate

Blogbeiträge passend zum Vortrag

• http://www.databinding.net/nc/blog/post/2010/09/22/entity-framework-4-sql-optimierung-mit-query-rewrite.html
• http://www.databinding.net/nc/blog/post/2010/06/04/entity-framework-4-sql-abfragen-direkt-ausfuehren.html
• http://www.databinding.net/nc/blog/post/2010/08/22/eftracingprovider-und-die-notsupportedexception-bei-executestorequeryt.html
• http://www.databinding.net/nc/blog/post/2010/09/18/eftracingprovider-sql-log-im-database-engine-tuning-advisor-deta-verwenden.html
• http://www.databinding.net/nc/blog/post/2010/09/01/entity-framework-4-model-first-der-tph-strategie-mit-hilfe-des-entity-designer-database-generation.html
• http://www.databinding.net/nc/blog/post/2010/09/14/entity-framework-4-self-tracking-entities-mit-eftracing-und-efcachingprovider-unterstuetzung.html
• http://www.databinding.net/nc/blog/post/2010/10/03/entity-framework-4-query-rewrite-mit-eftracingprovider-simulieren.html