LINQ to SQL-Verweise auf Entitäten in anderen Datacontexts

Question

In meinem Datenbank-Design, neige ich dazu, „Cluster“ von Tabellen zu haben. Diese Cluster unterstützen typischerweise eine Applikation oder eine Gruppe von eng funktionsbezogene Anwendungen. Oft beziehen sich diese Cluster auch miteinander über eine relativ kleine Anzahl von Fremdschlüsseln; dies hilft, ansonsten unabhängige Anwendungen im Unternehmen miteinander zu integrieren.

So zum Beispiel: sich vorstellen, ich habe applications "Foo", "Bar" und "Baz", mit mehreren Tabellen für jeden von ihnen. Hier ist eine Liste der Tabellen und deren Fremdschlüssel-Referenzen:

• FooTableOne
• FooTableTwo -> FooTableOne
• BarTableOne -> FooTableTwo
• BarTableTwo -> BarTableone
• BazTableOne
• BazTableTwo -> FooTableTwo, BazTableOne

Derzeit bin ich mit LINQ-to-SQL für den Zugriff dieser Tabellen. Ich habe ein eigenes Projekt für jeden Cluster (Foo, Bar und Baz), und jedes dieser Projekte hat eine .dbml für alle Tabellen im Cluster. Die Idee dabei ist, dass jede (eine oder mehrere) Anwendung, dass Verwendungen der Cluster eine gemeinsam genutzte Bibliothek importieren können die LINQ-Klassen enthalten, die es braucht.

Dies kann oder kann nicht eine gute Idee sein; es sieht aus wie die Jury ist noch aus . Was ich frage mich wirklich, ob ich die Verweise zwischen dem von den Klassen in einem anderen Cluster ausgedrückt Cluster haben kann, auch wenn sie in einer anderen Kontext Klasse existieren. (Und, genauer gesagt, wie diese Beziehung in Visual Studio erstellen).

Gehen wir zurück zum Beispiel, würde ich gerne haben:

• Projekt Foo
  • Foo.dbml
  • FooDataContext
  • FooTableOne
    • FooTableOne.FooTableTwos
  • FooTableTwo
    • FooTableTwo.FooTableOne
    • FooTableTwo.BarTableOnes (dies ist nicht so wichtig)
    • FooTableTwo.BazTableTwos (dies ist nicht so wichtig)
• Projekt Bar
  • Bar.dbml
  • BarDataContext
  • BarTableOne
    • BarTableOne.FooTableTwo
    • BarTableOne.BarTableTwos
  • BarTableTwo
    • BarTableTwo.BarTableOne
• Projekt Baz
  • Baz.dbml
  • BazDataContext
  • BazTableOne
    • BazTableOne.BazTableTwos
  • BazTableTwo
    • BazTableTwo.FooTableTwo
    • BazTableTwo.BazTableOne

aus dem Tor, alle Verweise auf Out-of-context Einheiten sind einfach IDs (Ints), Objekte nicht, und die Sammlungen zu out-of-context Entitäten existieren gar nicht. Ich weiß, ich kann meine eigenen Methoden zu diesen Klassen fügen Sie die entsprechenden Lookups zu tun (eine Instanz des Kontextes gegeben), aber ich möchte die Dinge bekommen, ein wenig mehr rationalisiert und konsistent.

Beachten Sie, dass bei dieser Trennung von Kontexten / Cluster, ich Modularität zwischen Anwendungen bekommen. So würde zum Beispiel die Baz Anwendung nur die Baz und Foo Kontexte importieren müssen (da Baz auf Foo abhängt), aber nicht Bar. (Dies setzt voraus, dass ich nicht die Sammlungen von Bar Einheiten in Foo habe, was in Ordnung von mir ist). Dies ist eine schöne Sache, aber es ist nicht entscheidend. Wenn LINQ / VS dies nicht leicht, dann werde ich prüfen, die Modularität Verschrottung und ging mit einem großen Kontext

Answer 1

L2S kann nicht von Modellbeziehungen über DBML Dateien. IMO ist dies ein großes Manko von L2S. Ich kämpfte mit diesem in unserer Anwendung. Wir haben alle Einheiten in separaten DBML Dateien. Jede DBML Datei stellt einen Namespace in unserer Anwendung, und ein Schema in unserer SQL Server-Datenbank.

Also, was ich am Ende tun für jede Entität ist, das eine Eigenschaft hat, die eine ausländische Beziehung in einem anderen Namespace darstellt, habe ich eine benutzerdefinierte Vereinigung Attribut auf dem Grundstück in einer Teilklasse, dass ahmt die L2S Vereinigung Attribut. Dieses benutzerdefinierte Attribut ermöglicht es uns, die Beziehungen selbst zu verwalten. Nicht ganz so effizient wie mit L2S es tun, aber es funktioniert ziemlich gut für uns.

Randy