studio - LINQ to SQL: Multiple/Single.dbml por proyecto?

sql metal

Question

Leí el artículo de Rick Strahl sobre Linq para SQL DataContext Lifetime Management con la esperanza de encontrar algunas respuestas sobre cómo administraría mis archivos .dbml, ya que están estrechamente relacionados con DataContext. Desafortunadamente, el artículo de Rick parece centrarse en la duración de DataContext durante el tiempo de ejecución , y mi pregunta es sobre cómo deberían organizarse los .dbml en tiempo de diseño .

La pregunta general sobre ''Mejores prácticas con .dbml''s'' se ha formulado y respondido aquí , y las respuestas se han centrado en herramientas externas para administrar el archivo .dbml.

Estoy haciendo una pregunta más centrada sobre cuándo y por qué no debería tener un solo archivo .dbml en su proyecto LINQ to SQL .

Answer 1

En mi opinión, puede dividir los archivos .dmbl para que cada uno mantenga un subconjunto de tablas / procesos de un DB de acuerdo con la función y la relación. No he hecho esto todavía así que esto es solo opinión.

Sin embargo, he creado varios archivos .dbml para ayudar con las pruebas unitarias. Si trabaja en un entorno que le restringe el uso de procesos almacenados en su entorno de producción, entonces no puede usar la parte de la tabla de .dbml (aunque puede usar la parte de proceso). Entonces, si "prueba la unidad" (esto es realmente una prueba de integración) de la capa de DB de tu código, puedes llamar al contenedor de proc y luego verificar los resultados consultando las tablas a través de la interfaz .dbml. En casos como este, dividiré el archivo .dmbl en las tablas que quiero consultar en mi "prueba de unidad".

Más información: Tengo 2 soluciones que construyo. Uno tiene pruebas unitarias y nunca se construye en el servidor de compilación. El otro se basa en el servidor de compilación y se implementa para probar / producción.

Answer 2

Yo diría que siempre solo necesitas 1 archivo dbml por base de datos. Si tiene múltiples conexiones a otras bases de datos, considere diseñar o usar archivos dbml separados. De cualquier manera, uno es suficiente por base de datos.

Esto debido a que el dbml se asigna a sus tablas y por qué no solo usa un "conector de datos" / "capa de datos" para eso, parece extraño / extraño el diseño para usar más de uno.

Es probablemente más controlable usando solo 1 aswell.

Answer 3

La respuesta es difícil porque es lo que la situación requiere. Intento separar lógicamente cada DBML en contextos (después de todo, DBML proporciona la funcionalidad DataContext). Entonces, si mi aplicación tiene un contexto único, entonces no tiene sentido que tenga un DBML separado para cada tabla. El contexto es el rey cuando creo tus archivos DBML es lo que digo.

Answer 4

Digamos que tiene una base de datos:

La base de datos D contiene tablas A, B, C, X, Y, Z donde

• La tabla A tiene una relación de clave externa con las tablas B y C
• La tabla X tiene una relación de clave externa con las tablas Y y Z
• La Tabla X también tiene una relación de clave externa con la tabla A

Supongamos que tiene 2 archivos DBML P y Q basados ​​en la base de datos D

• El archivo P de DBML contiene las entidades A '', B'' y C ''donde A'' está conectado a B ''y C'' mediante asociaciones.
• El archivo DBML Q contiene entidades X '', Y'' y Z ''donde X'' está conectado a Y ''y Z'' a través de asociaciones.

AFAIK, no hay forma de que los archivos DBML P y Q contengan una asociación entre las entidades A ''y X''. Este es el mayor problema con tener múltiples archivos DBML.

En mi opinión, un archivo DBML refleja el modelo de datos representado por las tablas y las restricciones en esas tablas en una base de datos. Si faltan algunas tablas o restricciones de un conjunto de archivos DBML, entonces el conjunto de archivos DBML no refleja con precisión la base de datos subyacente.

Volviendo a nuestro ejemplo, si no hubiera relación entre las tablas A y X en la base de datos D, entonces uno podría crear 2 archivos DBML.

Genéricamente hablando, uno puede tener múltiples archivos DBML si cada archivo DBML contiene todas las entidades y relaciones que están conectadas. Tenga en cuenta que el inverso no es un problema, es decir, uno puede tener un solo archivo DBML que contenga múltiples grupos de entidades que no están relacionadas entre sí por ninguna asociación.

Answer 5

Otra cosa a tener en cuenta es que LINQ usa DataContext para rastrear las identidades de las instancias de las entidades que crea. Por lo tanto, una entidad que representa una fila en una tabla creada por una instancia de la clase DataContext no es la misma que una creada por otra, incluso si todas las propiedades son las mismas.

Cuando uno tiene múltiples archivos DBML, entonces por necesidad, habrá múltiples instancias de DataContexts, una para cada archivo DBML. Por lo tanto, las entidades no se pueden unir o compartir de un DataContext a otro.

Esto es aplicable cuando una entidad existe en ambos (o todos) los archivos DBML.

Answer 6

Tenga en cuenta que LINQ2SQL está pensado para una forma simple y fácil de manejar la relación de la base de datos con los objetos.

No rompa la relación de tabla y conceptos de unidades de trabajo creando múltiples archivos .dbml.

Si alguna vez necesita crear múltiples archivos .dbml (que no recomiendo), intente satisfacer lo siguiente:

1. Si crea múltiples bases de datos sin relación entre esas tablas de base de datos.
2. Si desea utilizar uno de estos .dbml solo para manejar procedimientos almacenados
3. Si no te importa el concepto de unidad de trabajo.

Si su base de datos es demasiado compleja, entonces consideraría ORM como NHibernate, EF 4

Answer 7

Este problema se ha analizado a fondo aquí: http://craftycode.wordpress.com/2010/07/19/linq-to-sql-single-data-context-or-multiple/

En resumen, debe crear como máximo un contexto de datos por grupo de tablas fuertemente conectadas, o un contexto de datos por base de datos.

Answer 8

Sí, hm, leí el análisis completo en craftycodeblog, pero ¿no sería bueno si pudieras obtener todos los beneficios de ambos lados?

Quiero tener un único DataContext para mi aplicación, pero aún así dividirlo en múltiples archivos .dbml (y múltiples archivos dbml.layout y designer.cs). Supongo que esto no es compatible con Visual Studio, pero resolvería todos los problemas.

El caso de uso es el siguiente: una aplicación grande se compone de varios módulos, cada uno de los cuales agrega un conjunto de tablas (y, por supuesto, código) a la aplicación (es decir, a una única base de datos) y tiene acceso al código y las tablas de otros módulos.

Digamos que el módulo ABC define las tablas A, B, C y el módulo XYZ define las tablas X, Y, Z. Las tablas XYZ pueden tener claves externas a las tablas ABC. Sería mejor si: * Al trabajar con el código del módulo ABC, "ve" únicamente las tablas ABC, tanto en el diseñador como en el editor linq. * Al trabajar con el código del módulo XYZ, puede ver solo tablas XYZ en el diseñador de dbml, para que pueda reducir el desorden y ver solo el esquema de su módulo. El editor de linq debe tener acceso a las tablas ABC y XYZ.