LINQ to SQL I riferimenti alle entità in altre DataContexts

Question

Nei miei disegni di database, che tendono ad avere "cluster" di tabelle. Questi cluster in genere supportare un'applicazione o un gruppo di applicazioni strettamente funzionalmente correlati. Spesso, questi cluster riferiscono anche tra loro attraverso un numero relativamente piccolo di chiavi esterne; questo aiuta applicazioni altrimenti indipendenti nel settore si integrano con l'altro.

Così, per esempio: immaginate ho applicazioni "Pippo", "Bar", e "Baz", con diversi tavoli per ciascuno di essi. Ecco un elenco delle tabelle e dei loro riferimenti chiave esterna:

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

Al momento, sto usando LINQ to SQL per accedere a queste tabelle. Ho un progetto separato per ogni cluster (Foo, Bar e Baz), e ciascuno di questi progetti hanno una .dbml per tutte le tabelle del cluster. L'idea è che ciascuno (uno o più) applicazione che utilizza il cluster può importare una libreria condivisa che contiene le classi LINQ di cui ha bisogno.

Questo può o non può essere una buona idea; sembra che il giuria è https://stackoverflow.com/questions/1591822/linq-to-sql-multiple-data-context-in-same-transaction ancora fuori. Quello che sto veramente chiedendo è se o non posso avere i riferimenti tra i cluster espressi dalle classi in un altro gruppo, anche se esistono in una diversa classe di contesto. (E, più specificamente, come creare questo rapporto in Visual Studio).

Tornando all'esempio, mi piacerebbe avere:

• Foo Progetto
  • Foo.dbml
  • FooDataContext
  • FooTableOne
    • FooTableOne.FooTableTwos
  • FooTableTwo
    • FooTableTwo.FooTableOne
    • FooTableTwo.BarTableOnes (questo non è importante)
    • FooTableTwo.BazTableTwos (questo non è importante)
• Progetto Bar
  • Bar.dbml
  • BarDataContext
  • BarTableOne
    • BarTableOne.FooTableTwo
    • BarTableOne.BarTableTwos
  • BarTableTwo
    • BarTableTwo.BarTableOne
• Progetto Baz
  • Baz.dbml
  • BazDataContext
  • BazTableOne
    • BazTableOne.BazTableTwos
  • BazTableTwo
    • BazTableTwo.FooTableTwo
    • BazTableTwo.BazTableOne

Fuori della porta, tutti i riferimenti a entità out-of-contesto sono gli ID semplici (INT), non oggetti, e le collezioni di out-of-context non esistono entità a tutti. So che posso aggiungere i miei metodi per queste classi per fare le ricerche opportune (data un'istanza del contesto), ma mi piacerebbe fare le cose un po 'più snelle e coerenti.

Si noti che, con questa separazione dei contesti / cluster, ottengo modularità tra le applicazioni. Così, per esempio, l'applicazione Baz avrebbe solo per importare i contesti Baz e Foo (dal Baz dipende Foo), ma non bar. (Questo presuppone che non ho le collezioni di entità Bar in Foo, che è bene per me). Questa è una cosa bella, ma non è fondamentale. Se LINQ / VS non rende questo facile allora io considero la demolizione la modularità e andare con uno-big-contesto

Answer 1

L2S non può modellare le relazioni attraverso i file DBML. IMO, si tratta di una grave lacuna di L2S. Ho lottato con questo nella nostra applicazione. Abbiamo tutte le entità nei file DBML separati. Ogni file DBML rappresenta uno spazio dei nomi nella nostra applicazione, e di uno schema nel nostro database di SQL Server.

Quindi, quello che ho finito per fare è per ogni entità che ha una proprietà che rappresenta una relazione straniero in uno spazio diverso, ho messo un attributo Associazione personalizzato sulla proprietà in una classe parziale, che imita l'attributo L2S Association. Questo attributo personalizzato ci permette di gestire i rapporti noi stessi. Non è così efficiente come avere L2S farlo, ma funziona abbastanza bene per noi.

Randy