Hacer un palmo Entity Framework Modelo múltiples bases de datos

Question

¿Es válido hacer algo como

CREATE SYNONYM [dbo].[MyTable] FOR [AnotherDatabase].dbo.[MyTable]

y luego modificar el archivo edmx de Entity Framework para leer este objeto como lo haría cualquier otra tabla?

Me hicieron una prueba de muestra rápido y parece que funciona bien para la selección y puesta al día, pero quería saber si había alguna razón por la que no debería estar haciendo esto

estoy recibiendo la definición de la tabla de creando un archivo edmx apuntando a la segunda base de datos, construyendo las entidades allí, luego copiando/pegando la definición en el archivo edmx de la primera base de datos.

ACTUALIZACIÓN

Si alguien está interesado, escribí lo que hice para hacer una división del archivo de bases de datos edmx haya numerosas here. Incluye scripts para generar sinónimos y fusionar archivos de edmx.

Answer 1

Si hizo una prueba y funcionó probablemente haya mostrado algo que nadie más conoce. Hasta ahora siempre respondía a este tipo de preguntas: no es posible usar un solo modelo con dos bases de datos (con una solución más fea basada en vistas que ocultan tablas de la segunda base de datos). Ahora sé dos soluciones.

La única desventaja de este enfoque es que todos los cambios realizados manualmente en la parte SSDL de su EDMX siempre se perderán si ejecuta Actualizar el modelo desde la base de datos. Esto significa el desarrollo manual de EDMX (que es un trabajo bastante difícil) o el uso de alguna herramienta/script que agregará los cambios después de cada actualización de la base de datos.

Answer 2

También puede hacer esto con vistas (y un servidor vinculado si el otro db está en un servidor diferente). Esto evitará tener que administrar/fusionar dos archivos de edmx separados. Lo he usado con un servidor vinculado para leer datos de un segundo db en un servidor diferente, pero realicé algunas pruebas rápidas para ver si las actualizaciones/inserciones/eliminaciones eran posibles y lo son.

Tengo cero experiencia con las transacciones distribuidas, por lo que la información relacionada con las transacciones distribuidas puede ser buena, mala o un poco de ambas. Si sus dos db están en el mismo servidor I ASSUME transacciones distribuidas ya no se aplican.

Hay un par de cosas a tener en cuenta cuando se utiliza un servidor vinculado.

1. Al modificar las entidades en las tablas de datos enlazados y llama SaveChanges en su contexto, este intentará iniciar una transacción distribuida por lo menos alguien sabe cómo detener eso, es necesario asegurarse de que los dos servidores están configurados para manejar transacciones distribuidas. (Asumo que esto también sería cierto usando sinónimos).
2. Las inserciones en entidades con columnas de identidad en el servidor vinculado lanzan una excepción porque ef intenta obtener la nueva identificación usando SCOPE_IDENTITY() y es nula. No sé si hay una forma de evitar esto. No tuve problemas para actualizar o eliminar entidades en el servidor vinculado con columnas de identidad.

En SQL Server Un

1. crear un servidor vinculado al servidor B (no llene esto si los DB están en el mismo servidor).
2. crear una vista en [ServerA].[MyDB] para cada tabla en [ServerB].[AnotherDB] desea acceder a

En EDMX

1. Añadir sus puntos de vista en el fichero de edmx
2. Borrar la configuración de clave de entidad de cada propiedad en el diseñador (incluido el pk real)
3. Restablecer la clave de entidad para el pk real
4. Añadir asociaciones según sea necesario
5. Grabar cambios

Por Actualizaciones/Inserción/Borra

1. haga clic derecho en el archivo de edmx y abierto con el editor XML
2. Vaya a la StorageModel - >Schema ->EntityContainer
3. Encuentra el conjunto de entidades para tu entidad y elimina el DefiningQuery elemento
4. Encuentra el atributo store:Schema en el conjunto de entidades y elimina store: para que solo sea Schema. Deje su valor solo.
5. Repita los pasos 3 & 4 para cada vista desde el servidor vinculado
6. Guardar cambios

Debido a que el uso de un servidor vinculado crea una transacción distribuida que tenía que hacer un par de cosas en el ObjectContext antes SaveChanges fue un éxito .

ctx.Connection.Open(); 
ctx.ExecuteStoreCommand("set xact_abort on"); 
ctx.SaveChanges(); 
ctx.Connection.Close(); 

probablemente Puede crear una costumbre ObjectContext y anular SaveChanges añadir estas cosas en.

Answer 3

me he dado cuenta que este truco funciona con sinónimos perfectamente con el enfoque "Código primera" y sin ningún tipo de manipulación con archivos edmx!

Lo único que tienes que hacer es "enlazar" tu clase al sinónimo apropiado en el método OnModelCreating de tu DataContext.

Por ejemplo, si tengo un sinónimo a la mesa Personal en otra base de datos (y el nombre de la clase es también personal), y el nombre del sinónimo es "miesquema.MySynonym" entonces el método OnModelCreating deberían parece:

protected override void OnModelCreating(DbModelBuilder modelBuilder) 
    { 
     modelBuilder.HasDefaultSchema("myschema"); 

     modelBuilder.Entity<Personnel>() 
      .ToTable("MySynonym"); 

     Database.SetInitializer<TestSynonymContext>(null); 

     base.OnModelCreating(modelBuilder); 
    }