LINQ to SQL Referencias a Entidades en otros DataContexts

Question

En mi base de datos de diseños, que tienden a tener "grupos" de las tablas.Estos grupos se suelen admitir una aplicación o grupo de bien-funcionalmente relacionados con las aplicaciones.A menudo, estos grupos también se relacionan entre sí a través de un número relativamente pequeño de claves foráneas;esto ayuda a que de otra manera independiente de las aplicaciones en el negocio de integrar el uno con el otro.

Así, por ejemplo:imagine que tiene aplicaciones "Foo", "Bar", y "Baz", con varias mesas para cada uno de ellos.Aquí está una lista de las tablas y las referencias clave:

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

Actualmente, estoy usando LINQ to SQL para acceder a estas tablas.Tengo un proyecto independiente para cada uno de los clusters (Foo, Bar, y Baz), y cada uno de estos proyectos .dbml para todas las tablas en el clúster.La idea aquí es que cada uno (uno o más) de la aplicación que utiliza el clúster puede importar una biblioteca compartida que contiene el LINQ de las clases que necesita.

Esto puede o puede no ser una buena idea;parece que el jurado es todavía fuera.Lo que yo estoy preguntando es si puedo o no tener las referencias entre los grupos expresadas por las clases en otro grupo, incluso a pesar de que existen en un contexto diferente clase.(Y, más específicamente, cómo crear esta relación en Visual Studio).

Volviendo al ejemplo, me gustaría tener:

• Proyecto De Foo
  • Foo.dbml
  • FooDataContext
  • FooTableOne
    • FooTableOne.FooTableTwos
  • FooTableTwo
    • FooTableTwo.FooTableOne
    • FooTableTwo.BarTableOnes (este no es tan importante)
    • FooTableTwo.BazTableTwos (este no es tan importante)
• Proyecto De Bar
  • De la barra.dbml
  • BarDataContext
  • BarTableOne
    • BarTableOne.FooTableTwo
    • BarTableOne.BarTableTwos
  • BarTableTwo
    • BarTableTwo.BarTableOne
• Proyecto De Baz
  • Baz.dbml
  • BazDataContext
  • BazTableOne
    • BazTableOne.BazTableTwos
  • BazTableTwo
    • BazTableTwo.FooTableTwo
    • BazTableTwo.BazTableOne

Fuera de la puerta, todas las referencias a fuera-de-contexto entidades son simples Identificadores (ints), no a los objetos, y las colecciones del hacia fuera-de-contexto entidades no existen en absoluto.Sé que puedo agregar mis propios métodos de estas clases para hacer la correspondiente búsquedas (dada una instancia del contexto), pero me gustaría tener las cosas un poco más ágil y consistente.

Tenga en cuenta que, con esta separación de contextos/clusters, tengo modularidad entre aplicaciones.Así, por ejemplo, el Baz aplicación, sólo tiene que importar el Baz y Foo contextos (desde Baz depende de Foo), pero no de la Barra.(Esto supone que no tengo las colecciones de la Barra de entidades en Foo, que está bien por mí).Esta es una buena cosa, pero no crítico:si LINQ/VS no hacer esto fácil, a continuación, voy a considerar el desguace de la modularidad y va con uno de los grandes contexto.

Answer 1

L2S no puede relaciones de modelos a través de archivos DBML. OMI, esto es un defecto importante de L2S. Luché con esto en nuestra aplicación. Tenemos todas las entidades en archivos separados DBML. Cada archivo DBML representa un espacio de nombres en nuestra aplicación, y un esquema de base de datos SQL Server.

Por lo tanto, lo que terminó haciendo es para cada entidad que tiene una propiedad que representa una relación exterior en un espacio de nombres diferente, me puso un atributo Asociación personalizada en la propiedad en una clase parcial, que imita el atributo Asociación L2S. Este atributo personalizado nos permite gestionar las relaciones nosotros mismos. No es tan eficiente como tener L2S hacerlo, pero funciona bastante bien para nosotros.

Randy