Ich füge die gleiche Tabelle in mehreren Entity Framework begrenzten Kontext

Question

Ich habe eine ziemlich große Datenbank, etwa 80 Tabellen oder so. Also habe ich beschlossen, die Tabellen in einen beschränkten Kontext zu trennen, anstatt alle 80 Tabellen in einer großen edmx-Datei zu haben.

So habe ich begrenzt Kontexte wie Vertrieb, Kunden, usw.

Ich habe meine Haupt-Kundentabelle in meinen Kunden edmx Datei. Ich muss jedoch auch auf bestimmte Felder zugreifen, nicht nur auf 1 oder 2 Felder (z. B. brauche ich nur den Kundennamen anstelle des gesamten Kundenobjekts/der Tabelle) aus der Kundentabelle aus dem Sales edmx-Kontext.

Muss ich die gesamte Kundentabelle in die Sales edmx-Datei einfügen? Was ist die beste Vorgehensweise für dieses Szenario?

Answer 1

Es gibt ein paar zugrunde liegenden Probleme mit diesem Ansatz (IMO):

EF, wie jede ORM, fällt in die Persistenz Sorge. Daher sollte es nicht stören, wie Sie Ihr Domänenmodell strukturieren. Die Tatsache, dass Sie alle Entitäten beibehalten haben, die wie ein persistenter Speicher klingen, kann ein Hinweis darauf sein, dass sich Ihre beschränkten Kontexte überlappen oder nicht vorhanden sind.

Der Versuch, zu einer besseren Struktur zu bewegen, ist keine schlechte Sache :) --- aber, wie Mark Oreta sagte, würde ich wahrscheinlich nicht mit der EF-Struktur stören.

Das Hauptproblem, auf das Sie stoßen, wird dadurch verursacht, dass Sie versuchen, von Ihrem Domänenmodell zu lesen. Dies scheint in Systemen allzu oft aufzutauchen und macht die Dinge ziemlich schwierig. Lazy-Loading ist das direkte Ergebnis von genau diesem. Wenn Sie lesen, sollten Sie im Idealfall eine Abfrageebene mit Zugriff auf einen Abfragespeicher (möglicherweise die gleiche Datenbank) verwenden, der für das Lesen optimiert ist. In Ihrem Beispiel benötigen Sie einen denormalisierten Kundennamen in Ihrer Verkaufsdomäne. Das ist gut. Der Versuch, dies zu erreichen, indem Sie Ihr Domänenmodell lesen und dann versuchen, Daten aus einem Domänenmodell in einem anderen beschränkten Kontext einzuziehen, verursacht Ihnen den Schmerz.

Wenn Sie die Route der Teilung Ihrer Daten gehen, dann müssen Sie halten es Split.

Obwohl die Daten von verschiedenen BCs alle im selben Speicher sein können, sollten Sie Ihre Daten so betrachten, als ob jeder BC über eine eigene Datenbank verfügt. Manchmal habe ich ein einzelnes Projekt mit verschiedenen Problemen (Ebenen zu einigen) in verschiedenen Ordnern/Namespaces (.NET hier). Es sollte möglich sein, diese Bedenken nach Belieben in separate Zusammenstellungen zu zerlegen. Sie sollten also nicht zu eng gekoppelt sein. Dasselbe gilt für diese Datenstruktur, die Sie zu teilen versuchen. Sie sollten im Wesentlichen in der Lage sein, die relevanten BC-Daten in eine separate Datenbank aufzuteilen. Die Mechanismen, um Daten über die BCs zu bekommen, sind eine andere Sache und ich denke, wenn das nicht angegangen werden kann, kann es für Sie schwierig werden.

Obwohl ich glaube nicht, dass BCs von der Datenseite zu identifizieren beste Idee sein kann, es ist sicherlich ein Schritt in der richtigen Richtung :)

Answer 2

Wenn Sie mit einer Navigationseigenschaft (Sale.Customer) auf die Customer-Entität von Ihrer Sales-Entität zugreifen möchten, müssen Sie sie zur Verkaufs-EDMX hinzufügen.

Es ist nicht unbedingt eine schlechte Sache, alle Ihre Tabellen in einer einzigen edmx zu haben, solange Sie es erstellen, es für die Aktion (en) verwenden, die Sie wollen, und dann entsorgt es das Objektdiagramm nicht so groß werden.

Wenn Sie die beschränkten Kontexte beibehalten möchten, können Sie alternativ ein Repository oder etwas nach ID abrufen, wenn Sie es benötigen.

var customer = customerContext.GetCustomerById(sale.CustomerId); 

Answer 3

Ich mag Julie Lerman Ansicht zu diesem Thema http://msdn.microsoft.com/en-us/magazine/jj883952.aspx

I Verwenden Sie beschränkte Kontexte für die Zugriffsleistung, da die Ladezeit von Kontexten bei Verwendung kleinerer db-Kontexte sogar bei Verwendung generierter Ansichten schneller ist. Einfach das Zugangsmodell zu vereinfachen ist ein nettes Extra. Leistung berücksichtigen Tipps auf MS ef Site: http://msdn.microsoft.com/en-us/data/hh949853

BCs können auch andere Vorteile wie die Beschränkung des Zugriffs auf Geschäftsprobleme zu ermöglichen. Die größeren Probleme treten auf, wenn Sie versuchen, mit db-Kontexten zu arbeiten, die nicht nur in den DBSet-Versionen variieren, sondern auch versuchen, die Model-Ansichten zu ändern. Ich denke, das ist am besten außerhalb von EF getan und kartiert.

Ich verwende einen großen SUPERSET-Kontext, um die DB-Erstellung/Migration zu verwalten. Aber nicht täglicher Zugang.

Kleinere DB-Contexte werden für den täglichen Zugriff auf Daten verwendet.

Also ja auf alle Fälle begrenzte Kontexte verwenden. Dies kann gegen den SAME-Datenspeicher sein. Und um die Frage zu beantworten als "Ja die gleiche Tabelle (DbSet) kann in vielen Kontexten auftreten.