Sind mehrere DataContext-Klassen jemals geeignet?

Question

Um vollständig LinqToSql in einer ASP.net 3.5-Anwendung zu verwenden, ist es notwendig, erstellen DataContextclasses (die in der Regel mit dem Designer in VS 2008 erfolgt). Aus Sicht der Benutzeroberfläche ist der DataContext ein Entwurf der Abschnitte Ihrer Datenbank, die Sie über LinqToSql verfügbar machen möchten, und ist ein wesentlicher Bestandteil beim Einrichten der ORM-Funktionen von LinqToSql.

Meine Frage ist: Ich gründe ein Projekt, das auch eine große Datenbank verwendet, in der alle Tabellen in irgendeiner Weise durch Fremdschlüssel miteinander verbunden sind. Meine erste Neigung besteht darin, eine riesige DataContext-Klasse zu erstellen, die die gesamte Datenbank modelliert. So kann ich in der Theorie könnte (obwohl ich weiß nicht, ob dies in der Praxis benötigt wird) verwenden, um die Fremdschlüssel-Verbindungen, die durch LinqToSql erzeugt werden, leicht zwischen verwandten Objekten in meinem Code gehen, verwandte Objekte einfügen usw.

Nachdem ich jedoch darüber nachgedacht habe, denke ich jetzt, dass es sinnvoller sein könnte, mehrere DataContext-Klassen zu erstellen, die sich jeweils auf einen bestimmten Namespace oder einen logisch zusammenhängenden Abschnitt innerhalb meiner Datenbank beziehen. Mein Hauptanliegen ist, dass das Instanziieren und Entsorgen einer großen DataContext-Klasse für einzelne Operationen, die sich auf bestimmte Bereiche der Datenbank beziehen, eine unnötige Aussetzung für Anwendungsressourcen darstellen würde. Darüber hinaus ist es einfacher, kleinere DataContext-Dateien als eine große Datei zu erstellen und zu verwalten. Die Sache, die ich verlieren würde, ist, dass es einige entfernte Abschnitte der Datenbank geben würde, die nicht durch LinqToSql navigierbar wären (obwohl eine Kette von Beziehungen sie in der tatsächlichen Datenbank verbindet). Außerdem würden einige Tabellenklassen in mehr als einem DataContext vorhanden sein.

Irgendwelche Gedanken oder Erfahrungen darüber, ob mehrere DataContexte (entsprechend DB-Namespaces) anstatt (oder zusätzlich zu) einer sehr großen DataContext-Klasse (entsprechend der gesamten DB) geeignet sind?

Answer 1

Ich bin nicht einverstanden mit Johns Antwort. Der DataContext (oder Linq to Entities ObjectContext) ist eher eine "Arbeitseinheit" als eine Verbindung. Es verwaltet die Änderungsverfolgung usw.Sehen Sie dieses Blog-Post für eine Beschreibung:

Lifetime of a LINQ to SQL DataContext

Die vier wichtigsten Punkte dieses Blog-Post, dass Datacontext:

1. ideal für eine "Arbeitseinheit" Ansatz geeignet ist
2. Ist auch für "zustandslosen" Server-Betrieb
3. ist nicht für entwickelt Langlebige Verwendung

4. Should be used very carefully after 
   any SumbitChanges() operation. 
   

man bedenkt, dass ich glaube nicht, mehr als ein Datacontext verwenden würde in der Tat jede harm tun, unterschiedliche Datacontexts für verschiedene Arten von Arbeit der Erstellung Ihrer LinqToSql impelmentation mehr usuable und organisiert machen würde helfen. Der einzige Nachteil ist, dass Sie sqlmetal nicht verwenden können, um Ihr dmbl automatisch zu generieren.

Answer 2

Nach meiner Erfahrung mit LINQ to SQL und LINQ to Entities ein Datacontext ist ein Synonym für eine Verbindung zur Datenbank. Wenn Sie also mehrere Datenspeicher verwenden, müssen Sie mehrere DataContexts verwenden. Meine Bauchgefühlsreaktion ist, dass Sie mit einem DataContext, der eine große Anzahl von Tabellen umfasst, nicht viel von einer Verlangsamung bemerken würden. Wenn Sie dies jedoch tun, können Sie die Datenbank immer logisch an Punkten aufteilen, an denen Sie Tabellen isolieren können, die keine Beziehung zu anderen Tabellensätzen haben, und mehrere Kontexte erstellen.

Answer 3

ich die gleiche Frage Gerangel über während Nachrüsten LINQ hatte bereits über eine Legacy-DB auf SQL. Unsere Datenbank ist ein bisschen groß (150 Tabellen) und nach einigem Nachdenken und Experimentieren entschied ich mich für mehrere DataContexte. Ob dies als ein Anti-Pattern betrachtet wird, bleibt abzuwarten, aber für jetzt macht es das Leben überschaubar.

Answer 4

Ich denke John ist richtig.

„Meine größte Sorge ist, dass der Instanziierung und eine riesige Datacontext-Klasse die ganze Zeit für einzelne Operationen Entsorgung, die auf bestimmte Bereiche der Datenbank beziehen würde eine unnötige Zumutung für Anwendungsressourcen sein zu verhängen“

Wie unterstützen Sie, dass Erklärung? Was ist Ihr Experiment, das zeigt, dass ein großer DataContext ein Leistungsengpass ist? Mehrere Datenkontexte zu haben ist ähnlich wie mehrere Datenbanken und macht in ähnlichen Szenarien Sinn, das heißt, fast nie. Wenn Sie mit mehreren Datenkontexten arbeiten, müssen Sie verfolgen, welche Objekte zu welchem ​​Datenkontext gehören, und Sie können keine Objekte zuordnen, die sich nicht im selben Datenkontext befinden. Das ist ein teurer Designgeruch ohne wirklichen Nutzen.

@Evan "Der DataContext (oder Linq to Entities ObjectContext) ist eher eine" Einheit der Arbeit "als eine Verbindung" Genau deshalb sollten Sie nicht mehr als einen Datenkontext haben. Warum möchtest du mehr als eine "Einheit der Arbeit" gleichzeitig?

Answer 5

Ich muss der angenommenen Antwort nicht zustimmen. In der gestellten Frage hat das System eine einzige große Datenbank mit starken Fremdschlüsselbeziehungen zwischen fast jeder Tabelle (auch wenn ich arbeite). In diesem Szenario bricht sie in kleinere Datacontexts (DCs) zwei unmittelbare und wesentliche Nachteile (beide von der Frage erwähnt):

1. Sie verlieren Beziehungen zwischen einigen Tischen. Sie können versuchen, Ihre DC-Grenzen mit Bedacht zu wählen, aber Sie werden schließlich in eine Situation geraten, in der es sehr bequem wäre, eine Beziehung von einer Tabelle in einem DC zu einer Tabelle in einem anderen zu verwenden.
2. Einige Tabellen können in mehreren DCs erscheinen. Wenn Sie also in Teilklassen tabellenspezifische Hilfsmethoden, Geschäftslogik oder anderen Code hinzufügen möchten, sind die Typen nicht über DC hinweg kompatibel. Sie können dies umgehen, indem Sie jede Entitätsklasse von ihrer eigenen spezifischen Basisklasse erben, was unordentlich wird. Außerdem müssen Schemaänderungen über mehrere Domänencontroller hinweg dupliziert werden.

Nun sind das erhebliche Nachteile. Gibt es Vorteile, die groß genug sind, um sie zu überwinden?Die Frage erwähnt Leistung:

Meine größte Sorge ist, dass der Instanziierung und eine riesige Datacontext-Klasse die ganze Zeit für einzelne Operationen freundlichen Entsorgung auf bestimmte Bereiche der Datenbank beziehen sich eine unnötige Auferlegung auf Anwendungsressourcen verhängen würde.

Tatsächlich ist es nicht wahr, dass ein großer DC wesentlich mehr Zeit benötigt, um in einer typischen Arbeitseinheit zu instanziieren oder zu verwenden. In der Tat, after the first instance is created in a running process, subsequent copies of the same DC can be created almost instantaneously.

Der einzige wirkliche Vorteil von mehreren Domänencontrollern für eine einzelne, große Datenbank mit gründlichen Fremdschlüsselbeziehungen ist, dass Sie Ihren Code ein wenig besser unterteilen können. Aber Sie können dies bereits mit partiellen Klassen tun.

Auch die Einheit der Arbeit Konzept ist nicht wirklich relevant für die ursprüngliche Frage. Arbeitseinheit bezieht sich typischerweise auf, wie viel eine Arbeit ein einzelner DC Instanz tut, nicht, wie viel Arbeit ein DC Klassefähig zu tun ist.