Referências Linq-to-SQL a entidades em outros Datacontexts

Question

Nos designs do meu banco de dados, costumo ter "aglomerados" de tabelas. Esses clusters normalmente suportam um aplicativo ou grupo de aplicações firmemente relacionadas a funcionários. Freqüentemente, esses aglomerados também se relacionam através de um número relativamente pequeno de chaves estrangeiras; Isso ajuda os aplicativos independentes nos negócios a integrar entre si.

Então, por exemplo: imagine que eu tenho aplicativos "foo", "bar" e "baz", com várias mesas para cada uma delas. Aqui está uma lista das tabelas e suas referências fundamentais:

• Fetoneone
• Footabletwo -> Fotone
• Bartableone -> footabletwo
• Bartabletwo -> BartableOne
• BaztableOne
• Baztabletwo -> Footabletwo, baztableOne

Atualmente, estou usando o LINQ para SQL para acessar essas tabelas. Eu tenho um projeto separado para cada clusters (Foo, Bar e Baz), e cada um desses projetos possui um .dbml para todas as tabelas do cluster. A idéia aqui é que cada aplicativo (um ou mais) que usa o cluster pode importar uma biblioteca compartilhada que contém as classes LINQ necessárias.

Isso pode ou não ser uma boa ideia; parece o júri é ainda Fora. O que estou realmente me perguntando é se posso ou não ter as referências entre os clusters expressos pelas classes em outro cluster, mesmo que existam em uma classe de contexto diferente. (E, mais especificamente, como criar esse relacionamento no Visual Studio).

Voltando ao exemplo, eu gostaria de ter:

• Projeto Foo
  • Foo.dbml
  • Foodatacontext
  • Fetoneone
    • Fetoneone.footabletwos
  • Footabletwo
    • Footabletwo.footableOne
    • Footabletwo.bartableones (este não é tão importante)
    • Footabletwo.baztabletwos (este não é tão importante)
• Barra de projeto
  • Bar.dbml
  • Bardatacontext
  • Bartableone
    • Bartableone.footabletwo
    • Bartableone.Bartabletwos
  • Bartabletwo
    • Bartabletwo.bartableOne
• Projeto Baz
  • Baz.dbml
  • Bazdatacontext
  • BaztableOne
    • BazTableOne.baztabletwos
  • Baztabletwo
    • Baztabletwo.footabletwo
    • Baztabletwo.baztableOne

Fora do portão, todas as referências a entidades fora de contexto são IDs simples (INTs), não objetos e as coleções de entidades fora de contexto não existem. Sei que posso adicionar meus próprios métodos a essas classes para fazer as pesquisas apropriadas (dada uma instância do contexto), mas gostaria de obter as coisas um pouco mais simplificadas e consistentes.

Observe que, com essa separação de contextos/clusters, recebo modularidade entre aplicações. Assim, por exemplo, o aplicativo Baz teria que importar os contextos Baz e Foo (já que o Baz depende do Foo), mas não da barra. (Isso pressupõe que eu não tenho as coleções de entidades de bares em Foo, o que é bom para mim). Isso é uma coisa boa, mas não é crítica: se o Linq/vs não facilitar isso, considerarei descartar a modularidade e seguir um contexto de um big.

Answer 1

L2S não pode modelar os relacionamentos nos arquivos DBML. IMO, esta é uma grande falha de L2s. Eu lutei com isso em nossa aplicação. Temos todas as entidades em arquivos DBML separados. Cada arquivo DBML representa um espaço para nome em nosso aplicativo e um esquema em nosso banco de dados do SQL Server.

Então, o que acabei fazendo é para cada entidade que possui uma propriedade que representa um relacionamento estrangeiro em um espaço de nome diferente, coloquei um atributo de associação personalizado na propriedade em uma classe parcial, que imita o atributo da associação L2S. Esse atributo personalizado nos permite gerenciar os relacionamentos. Não é tão eficiente quanto ter L2s, mas funciona muito bem para nós.

Randy