Sind mehrere Datacontext Klassen immer angemessen?

stimmen
27

Um in einer ASP.net 3.5 - Anwendung vollständig LinqToSql zu verwenden, ist es notwendig , erstellen Datacontext Klassen (die in der Regel geschieht mit Hilfe der Designer in VS 2008). Von der UI Sicht ist die Datacontext eine Gestaltung der Abschnitte Ihrer Datenbank , die Sie durch LinqToSql aussetzen möchten und sind ein integraler Bestandteil bei der Festlegung der ORM - Funktionen von LinqToSql auf.

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 ist eine riesige Datacontext-Klasse, die Modelle, die gesamte Datenbank zu machen. So kann ich in der Theorie könnte (obwohl ich weiß nicht, ob dies in der Praxis benötigt wird) verwenden die Fremdschlüssel-Verbindungen, die durch LinqToSql erzeugt werden, leicht zwischen verwandten Objekten in meinem Code zu gehen, verwandte Objekte einfügen, usw.

Doch nach einigem Überlegen, ich denke jetzt, dass es mehr Sinn machen, kann mehrere Datacontext Klassen, von denen jedem in Zusammenhang mit einem bestimmten Namensraum oder logisch miteinander verknüpften Abschnitt in meiner Datenbank zu erstellen. Mein Hauptanliegen ist, dass die Instanziierung und eine riesige Datacontext-Klasse des 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. Darüber hinaus ist es einfacher zu erstellen und zu verwalten kleinere Datacontext-Dateien als ein großer. Die Sache, die ich verlieren würde, ist, dass es einige entfernte Abschnitte der Datenbank sein würde, die nicht befahrbar sein würde durch LinqToSql (auch wenn eine Kette von Beziehungen sie in der eigentlichen Datenbank verbindet). Zusätzlich würde es einige Tabellenklassen, die in mehr als einem Datacontext existieren würde.

Irgendwelche Gedanken oder Erfahrungen auf, ob mehrere Datacontexts (entsprechend DB Namespace) geeignet sind, anstelle von (oder zusätzlich zu) einer sehr großen Datacontext-Klasse (entspricht dem gesamten DB)?

Veröffentlicht am 05/08/2008 um 06:54
quelle vom benutzer
In anderen Sprachen...                            


5 antworten

stimmen
25

Ich bin nicht einverstanden mit Johns Antwort. Der Datacontext (oder Linq to Entities Object) ist eher eine „Arbeitseinheit“ als eine Verbindung. Es verwaltet die Änderungsverfolgung, etc. Sehen Sie dieses Blog-Post für eine Beschreibung:

Lebensdauer einer LINQ to SQL Datacontext

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

  1. Ideal für eine „Arbeitseinheit“ -Ansatz geeignet
  2. Ist auch für „stateless“ Server-Betrieb ausgelegt
  3. Ist das nicht für Langlebig Einsatz konzipiert
  4. Should be used very carefully after
    any SumbitChanges() operation.
    

Bedenkt man, 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 organisiert mehr usuable und würde helfen. Der einzige Nachteil ist, dass Sie nicht in der Lage sein, Ihre dmbl zu verwenden sqlmetal automatisch generieren.

Beantwortet am 07/08/2008 um 22:02
quelle vom benutzer

stimmen
4

Ich hatte Gerangel wurde über die gleiche Frage während Nachrüsten LINQ über eine Legacy-DB auf SQL. Unsere Datenbank ist ein bisschen ein Whopper (150 Tabellen) und nach einigem Nachdenken und Experimentieren ich gewählt mehrere Datacontexts zu verwenden. Ob dies als ein Anti-Muster, bleibt abzuwarten, aber jetzt macht es das Leben überschaubar.

Beantwortet am 05/08/2008 um 23:51
quelle vom benutzer

stimmen
3

Ich habe mit der akzeptierten Antwort zu widersprechen. In der Frage gestellt, hat das System eine einzige große Datenbank mit starken Fremdschlüsselbeziehungen zwischen fast jedem Tisch (auch der Fall, wo 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 kommen, wo es sehr bequem wäre , in einer anderen zu einem Tisch in einer DC eine Beziehung aus einer Tabelle zu verwenden, und Sie werden nicht in der Lage.
  2. Einige Tabellen können in mehreren DCs erscheinen. Dies bedeutet , dass , wenn Sie tabellenspezifische Hilfsmethoden, Business - Logik hinzufügen möchten, oder anderen Code in Teilklassen, nicht die Typen über DC kompatibel sein. Sie können durch Erben jede Entität Klasse von seiner eigenen spezifischen Basisklasse dieses Problem umgehen, die chaotisch wird. Außerdem werden Schemaänderungen müssen über mehrere DCs dupliziert werden.

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

Mein Hauptanliegen ist, dass die Instanziierung und eine riesige Datacontext-Klasse des 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.

Eigentlich ist es nicht wahr , dass ein großer DC deutlich mehr Zeit in Anspruch nimmt in einer typischen Arbeitseinheit zu instanziiert oder zu verwenden. In der Tat, nachdem die erste Instanz in einem laufenden Prozess erstellt wird, können nachfolgende Kopien derselben DC fast augenblicklich erzeugt werden .

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

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

Beantwortet am 17/06/2014 um 21:53
quelle vom benutzer

stimmen
3

Ich glaube, John korrekt ist.

„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 werden verhängen“

Wie unterstützen Sie diese Aussage? Was ist Ihr Experiment, das zeigt, dass eine große Datacontext eine Performance-Engpass ist? mehr Datacontexts zu haben, ist ein viel wie mehrere Datenbanken mit und macht Sinn, in ähnlichen Szenarien, das heißt, so gut wie nie. Wenn Sie mit mehreren Datacontexts arbeiten müssen Sie den Überblick behalten, welche Objekte gehören zu dem Datacontext und Sie können keine Objekte beziehen, die nicht in dem gleichen Datenkontext sind. Das ist ein teures Design Geruch für keinen wirklichen Nutzen.

@ Evan „Der Datacontext (oder Linq to Entities Object) ist eher eine‚Arbeitseinheit‘als eine Verbindung“ Das ist genau das, warum Sie nicht mehr als eine Datacontext haben sollte. Warum wollen Sie mehr, dass man „Arbeitseinheit“ zu einem Zeitpunkt?

Beantwortet am 27/08/2008 um 02:11
quelle vom benutzer

stimmen
1

Nach meiner Erfahrung mit LINQ to SQL und LINQ to Entities ist ein Datacontext auch auf eine Verbindung zur Datenbank. Wenn Sie also mehrere Datenspeicher verwenden wären, würden Sie mehrere Datacontexts verwenden müssen. Mein Bauchgefühl ist, dass Sie nicht zu viel von einer Verlangsamung mit einem Datacontext, die eine große Anzahl von Tabellen umfassen bemerken würden. Wenn Sie jedoch haben können Sie immer die Datenbank aufgeteilt logisch an den Punkten, wo Sie Tabellen isolieren können, die keine Beziehung zu anderen Gruppen von Tabellen und mehrere Kontexte erstellen.

Beantwortet am 05/08/2008 um 10:57
quelle vom benutzer

Cookies help us deliver our services. By using our services, you agree to our use of cookies. Learn more