Wiederverwendbarer ObjectContext oder neuer ObjectContext für jeden Satz von Operationen?

Question

Ich bin neu im Entities Framework und fange gerade damit an, in meiner Freizeit damit herumzuspielen. Eine der wichtigsten Fragen, die ich habe, betrifft die Handhabung von ObjectContexts.

die allgemein bevorzugt/empfohlen davon ist:

Diese

public class DataAccess{ 

    MyDbContext m_Context; 

    public DataAccess(){ 
     m_Context = new MyDbContext();   
    } 

    public IEnumerable<SomeItem> GetSomeItems(){ 
     return m_Context.SomeItems; 
    } 

    public void DeleteSomeItem(SomeItem item){ 
     m_Context.DeleteObject(item); 
     m_Context.SaveChanges(); 
    } 
} 

Oder das?

public class DataAccess{ 

    public DataAccess(){ } 

    public IEnumerable<SomeItem> GetSomeItems(){ 
     MyDbContext context = new DbContext(); 
     return context.SomeItems; 
    } 

    public void DeleteSomeItem(SomeItem item){ 
     MyDbContext context = new DbContext(); 
     context.DeleteObject(item); 
     context.SaveChanges(); 
    } 
} 

Answer 1

Die Object soll die "Unit of Work" sein.

Im Wesentlichen bedeutet dies, dass für jede "Operation" (zB: jede Webseitenanforderung) eine neue ObjectContext-Instanz vorhanden sein sollte. Innerhalb dieser Operation sollte derselbe ObjectContext wiederverwendet werden.

Dies ist sinnvoll, wenn Sie darüber nachdenken, da Transaktionen und Änderungsvorlagen alle an die ObjectContext-Instanz gebunden sind.

Wenn Sie keine Web-App schreiben und stattdessen eine WPF- oder Windows Forms-Anwendung schreiben, wird es etwas komplexer, da Sie nicht den engen "Anfrage" -Bereich einer Webseite haben -load gibt dir, aber du hast die Idee.

PS: In beiden Beispielen ist die Lebensdauer des ObjectContext entweder global oder transient.In beiden Situationen sollte es nicht innerhalb der DataAccess-Klasse leben - es sollte als Abhängigkeit übergeben werden

Answer 2

Nur eine kurze Notiz - die beiden Codestück sind in etwa die gleichen in ihrem zugrunde liegenden Problem. Dies ist etwas, das ich mir angesehen habe, weil Sie den Kontext nicht weiter öffnen und schließen wollen (siehe zweites Beispiel), während Sie nicht sicher sind, ob Sie Microsoft vertrauen können, um den Kontext für Sie richtig zu beseitigen.

Eines der Dinge, die ich getan habe, war eine gemeinsame Basisklasse zu erstellen, die faul lädt den Kontext in und implementieren die Basisklasse destruction-er, Dinge zu entsorgen. Dies funktioniert gut für so etwas wie das MVC-Framework, führt aber leider zu dem Problem, dass der Kontext an die verschiedenen Schichten weitergegeben werden muss, damit die Geschäftsobjekte den Aufruf teilen können.

Am Ende habe ich mit etwas mit Ninject ging diese Abhängigkeit in jeder Schicht zu injizieren, und hatte es Nutzung

Answer 3

verfolgen Wenn Sie den gleichen Kontext für eine lang laufende Prozess läuft viele halten abfragt dagegen , linq-to-sql (Ich habe nicht gegen linq auf Entitäten getestet, aber ich denke, das ist das gleiche Problem) wird sehr langsam (1 Abfrage eine Sekunde nach etwa 1000 einfachen Abfragen). Die regelmäßige Erneuerung des Kontexts behebt dieses Problem und kostet nicht so viel.

Was passiert, ist, dass der Kontext jede Abfrage verfolgt, die Sie damit machen, also wenn es nicht auf eine Art zurückgesetzt wird, wird es wirklich fett ... Ein anderes Problem ist dann der Speicher, den es braucht.

Es hängt also hauptsächlich davon ab, wie Ihre Anwendung funktioniert und ob Sie eine DataAccess-Instanz regelmäßig neu erstellen oder ob Sie sie immer gleich behalten. Hoffe, das hilft.

Stéphane

Answer 4

Ich bin zwar nicht dafür, immer zu erstellen, was aber kompliziert sein muss, jedes Mal wenn ich sie brauche - auch ich haben festgestellt, dass die DataContexte in Linq to Sql und die ObjectContexts in EF am besten bei Bedarf erstellt werden.

Beide führen eine große statische Initialisierung basierend auf dem Modell aus, für das sie ausgeführt werden, das für nachfolgende Aufrufe zwischengespeichert wird. Daher wird der erste Startvorgang für einen Kontext länger dauern als alle nachfolgenden Instanziierungen. Die größte Hürde, der Sie dabei gegenüberstehen, ist die Tatsache, dass Sie, sobald Sie eine Entität aus dem Kontext erhalten, diese nicht einfach an eine andere übergeben können, um Aktualisierungsoperationen durchzuführen oder verknüpfte Entitäten wieder hinzuzufügen. In EF können Sie binden Sie eine Entität wieder an einen neuen Kontext an. In L2S ist dieser Prozess nahezu unmöglich.