LINQ to SQL Références aux entités autres DataContexts

Question

Dans mes conceptions de base de données, je tendance à avoir des « grappes » de tables. Ces groupes seront généralement plus d'une application ou d'un groupe d'applications liées étroitement fonctionnellement. Souvent, ces groupes sont également liés les uns aux autres par un nombre relativement restreint de clés étrangères; cela aide par ailleurs des applications indépendantes dans l'entreprise intègrent les uns aux autres.

Ainsi, par exemple: imaginez que j'ai des applications "Foo", "Bar" et "Baz", avec plusieurs tables pour chacun d'eux. Voici une liste des tables et leurs références clés étrangères:

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

À l'heure actuelle, j'utilise LINQ to SQL pour accéder à ces tables. J'ai un projet séparé pour chaque grappe (Foo, Bar et Baz), et chacun de ces projets ont un .dbml pour toutes les tables du cluster. L'idée ici est que chacun (un ou plusieurs) application qui utilise le cluster peut importer une bibliothèque partagée contenant les classes LINQ dont il a besoin.

Cela peut ou peut ne pas être une bonne idée; il ressemble à jury est https://stackoverflow.com/questions/1591822/linq-to-sql-multiple-data-context-in-same-transaction encore out . Ce que je me demande vraiment est de savoir si oui ou non je peux avoir les références entre les groupes exprimés par les classes dans un autre groupe, même si elles existent dans une classe de contexte différent. (Et, plus précisément, la façon de créer cette relation dans Visual Studio).

Pour en revenir à l'exemple, je voudrais avoir:

• Projet Foo
  • Foo.dbml
  • FooDataContext
  • FooTableOne
    • FooTableOne.FooTableTwos
  • FooTableTwo
    • FooTableTwo.FooTableOne
    • FooTableTwo.BarTableOnes (celui-ci est pas aussi important)
    • FooTableTwo.BazTableTwos (celui-ci est pas aussi important)
• Barre de projet
  • Bar.dbml
  • BarDataContext
  • BarTableOne
    • BarTableOne.FooTableTwo
    • BarTableOne.BarTableTwos
  • BarTableTwo
    • BarTableTwo.BarTableOne
• Projet Baz
  • Baz.dbml
  • BazDataContext
  • BazTableOne
    • BazTableOne.BazTableTwos
  • BazTableTwo
    • BazTableTwo.FooTableTwo
    • BazTableTwo.BazTableOne

Sur la porte, toutes les références à des entités hors de contexte sont ID simples (ints), pas les objets et les collections à des entités hors contexte n'existent pas du tout. Je sais que je peux ajouter mes propres méthodes pour ces classes pour faire les recherches appropriées (étant donné une instance du contexte), mais je voudrais faire avancer les choses un peu plus simples et cohérentes.

Notez que, avec cette séparation des contextes / clusters, je reçois la modularité entre les applications. Ainsi, par exemple, l'application Baz n'aurait à importer les contextes Baz et Foo (depuis Baz dépend de Foo), mais pas Bar. (Cela suppose que je n'ai pas les collections d'entités Bar à Foo, qui est bien pour moi). C'est une bonne chose, mais ce n'est pas critique. Si LINQ / VS ne fait pas facile, alors je considère que la modularité et la mise au rebut d'aller avec un grand contexte

Answer 1

L2S ne peut pas modéliser les relations entre les fichiers DBML. OMI, c'est une lacune majeure de L2S. Je luttais avec cela dans notre application. Nous avons toutes les entités dans les fichiers DBML séparés. Chaque fichier DBML représente un espace de noms dans notre application, et un schéma dans notre base de données SQL Server.

Alors, ce que je fini par faire est pour chaque entité qui possède une propriété qui représente une relation étrangère dans un autre espace de noms, je mets un attribut d'association personnalisée sur la propriété dans une classe partielle, qui imite l'attribut Association L2S. Cet attribut personnalisé nous permet de gérer les relations nous-mêmes. Pas tout à fait aussi efficace que d'avoir faire L2S, mais cela fonctionne assez bien pour nous.

Randy