Warum mehrere DbContext-Klassen?

8

Wenn ich LINQ mit einer .dbml-Datei programmiere, gibt es nur einen Kontext. Aber wenn ich eine MVC-Site mache, scheint es, als hätte ich separate Kontexte für jede Entität (so wie mir das MVC-Tutorial gezeigt hat, mit dem Kontext "Filme").

Ich habe:

%Vor%

Und ich habe:

%Vor%

Wenn ich diese anrufe, muss ich separate Kontexte erstellen, wie:

%Vor%

... Das ist sowohl lästig als auch redundant, da ich weiß, dass ich bei der Verwendung von LINQ nur ein einzelnes Datenbankobjekt instanziieren muss.

Gibt es eine Möglichkeit, nur einen Kontext zu verwenden, und wird dies empfohlen?

    
user1477388 25.04.2013, 23:26
quelle

1 Antwort

12

Es sollte nichts geben, was Sie daran hindert, einen Kontext zu verwenden. Die Datenbank und die Toolbox, die für den Zugriff verwendet wird, sollten vollständig unabhängig von allem sein, was sich außerhalb dieser befindet (Geschäftslogik, Service-Layer, UI usw.).

Die Anzahl der Kontexte oder wie Sie sie verwenden, sollte sich nicht aufgrund Ihrer Client-Technologie ändern.

Was ist mit MVC, wenn Sie glauben, dass Sie mehr als einen Kontext benötigen? Und was hält dich davon ab?

Wenn Sie glauben, dass Sie für jede Entität einen Kontext verwenden müssen, weil die Stichprobe auf diese Weise erstellt wurde, dann nicht. Verwenden Sie nur einen Kontext.

Wenn es hilft, sieht ein einfacher Kontext mit mehr als einer Entität aus:

%Vor%

Wenn es hilft, sieht ein typischer Geschäftsablauf so aus:

  

Benutzeroberfläche - & gt; Controller - & gt; Geschäftslogik - & gt; Datenzugriff - & gt; Datenbank

Ihre Datenkontexte würden in Ihre Datenschicht gehen. Ihre Logik würde in Ihrer Business-Logik-Ebene gehen.

    
Bob Horn 25.04.2013, 23:38
quelle