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

Question

He leído el artículo de Rick Strahl en Linq to 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 estar centrado en DataContext de por vida en el tiempo de ejecución, y mi pregunta se refiere a cómo los .dbml deben organizarse en tiempo de diseño.

La pregunta general sobre "Mejores prácticas con .dbml" has been asked and answered here, y las respuestas se han centrado en herramientas externas para administrar el archivo .dbml.

estoy haciendo una pregunta más precisa de cuándo y por qué en caso de que no tener un solo archivo .dbml en su LINQ a SQL proyecto basado?

Answer 1

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 interrumpa la relación de tabla y los conceptos de unidades de trabajo creando múltiples archivos .dbml.

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

1. Si crea varias bases de datos sin relación entre las tablas de la base de datos.
2. Si desea utilizar uno de estos .dbml solo para manejar los procedimientos almacenados
3. Si no le importa el concepto de unidad de trabajo.

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

Answer 2

Yo diría que siempre solo necesita 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 porque el dbml se asigna a sus tablas y por qué no solo utiliza un "conector de datos"/"capa de datos" para eso, parece extraño/raro el diseño para usar más de uno.

Probablemente sea más controlable usando solo 1 aswell.

Answer 3

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 4

La respuesta es complicada 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 5

Digamos que tiene una base de datos:

Base de Datos D contiene los cuadros A, B, C, X, Y, Z, donde

• tabla A tiene una extranjera relación clave con las tablas B y C
• tabla X tiene una relación de clave extranjera con mesas de y y Z
• tabla X también tiene una relación de clave externa con la tabla a

Digamos que tiene 2 archivos DBML P y Q basado en la base de datos D

• DBML Archivo P contiene entidades A 'B' y C 'donde A' está conectada a B ' y C' a través de 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 lo contrario no es un problema, es decir, uno puede tener un único archivo DBML que contenga múltiples grupos de entidades que no están relacionadas entre sí por ninguna asociación.

Answer 6

Otra cosa a tener en cuenta es que LINQ usa el 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, uno 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 7

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

En resumen, se debe crear como máximo una 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 pudiera obtener todos los beneficios de ambos lados?

Quiero tener un solo DataContext para mi aplicación, pero todavía lo divido 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 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.