2012-04-14 10 views
5

Ich bin neu in EF4, und ich versuche herauszufinden, die beste Möglichkeit, um meine DbContext-Klasse (n) zu erstellen.Sollte EF DbContext alle Tabellen enthalten?

Gibt es irgendein Problem (besonders Leistung), wenn ich alle meine Tabellen/Entitäten in eine und nur eine DbContext-Klasse setze, wie der Code unten?

public class AllInOneDb : DbContext 
{ 
    public DbSet<Customer> Customers{ get; set; } 
    public DbSet<Address> Addresses{ get; set; } 
    public DbSet<Order> Order{ get; set; } 
    public DbSet<Product> Products{ get; set; } 
    public DbSet<Category> Categories{ get; set; } 
    // and more and more entities... 
} 

Oder sollte ich meine Klassen basierend auf den Teilmengen von Funktionalitäten modellieren?

public class CustomerDb : DbContext 
{ 
    public DbSet<Customer> Customers{ get; set; } 
    public DbSet<Address> Addresses{ get; set; } 
    public DbSet<Order> Order{ get; set; } 
} 

public class ProductDb : DbContext 
{ 
    public DbSet<Product> Products{ get; set; } 
    public DbSet<Category> Categories{ get; set; } 
    public DbSet<Order> Order{ get; set; } // look Order entity again! 
} 

Dank

Antwort

7

Wenn Sie Teilbereiche haben, die spezifische Geschäftslogik haben, können Sie es in mehrere DbContext aufgeteilt. (Diese kleineren Kontexte folgen einem Muster, das für das Domain Driven Design mit der Bezeichnung Bounded Contexts entscheidend ist). Es gibt eine Reihe von Vorteilen beim Erstellen von DbContexts, die auf diese verschiedenen Prozesse ausgerichtet sind und nicht auf einen einzigen Allzweck-Kontext. Wenn Ihre Anwendung wächst, wird es viel einfacher sein, jeden Kontext zu pflegen und die Logik zu finden, die Sie darin benötigen. (Besser als Hinzufügen oder Ändern vorhandener Logik in einzelnen DbContext mit vielen DbSet Eigenschaften und flüssige Konfiguration für viele Klasse)

Leistung ist eine andere Überlegung. Wenn Entity Framework ein speicherinternes Modell des Kontexts erstellt, gilt: Je größer der Kontext ist, desto mehr Ressourcen werden für ausgegeben, um dieses In-Memory-Modell zu generieren und zu verwalten.

Wenn Sie Instanzen (Order) für mehrere Kontexte freigeben möchten, kann Entity nur an jeweils einen Kontext angehängt werden. Trennen Sie zuerst die Bestellung vom Kunden DbContext und hängen Sie die Bestellung an einen Produkt DbContext an. Und Sie sollten vorsichtig sein, wenn Sie hinzugefügte, geänderte oder gelöschte Entitäten von einem Kontext in einen anderen verschieben.

Order order; 
using (var custDb = new CustomerDb()){ 
    order = custDb.FirstOrDefault(o=>OrderId == "orderid"); 
} 
using (var prodDB = new ProductDb()){ 
    prodDB.Attach(order); 
    ... 
} 
+0

Bounded Contexts kann definitiv eine gute Idee sein! Der Performance-Hit kann jedoch ignoriert werden ... Die Erstellung des Modells dauert länger, aber das geschieht nur beim Start. Es gibt viele Tricks, um es so schnell wie möglich zu halten. Weitere Informationen in einigen Videos: http://pluralalsight.com/training/Courses/TableOfContents/efarchitecture – Jowen

Verwandte Themen