A Linq to Sql - Múltiples archivos .DBML o un archivo .DBML

Question

Estoy trabajando en una aplicación web con ASP.NET 3.5. La aplicación tiene cientos de tablas. Me dijeron en un seminario que debería usar un archivo .DBML para la aplicación completa en lugar de usar múltiples archivos .DBML (también había una publicación en stackoverflow que decía lo mismo). Dado que tengo tantas tablas, ¿tiene sentido usar un archivo .DBML o me conviene crear múltiples archivos .DBML que estén lógicamente agrupados?

Por ejemplo, yo estaba pensando en la creación de los siguientes archivos: .dbml

• cliente
• vendedor
• Empleado
• orden de venta

Una de las preocupaciones que yo tener sobre el uso de múltiples archivos .DBML es cómo manejaría las actualizaciones en los archivos .DBML. Por ejemplo, si tuve que actualizar un campo en la tabla de clientes cuando se ingresó un nuevo pedido de venta. ¿Cómo manejaría eso? Ciertamente no quiero incluir la tabla de clientes en los archivos .DBML del cliente y de la orden de venta. ¿Podría envolver las operaciones en un TransactionScope?

No sé si lo siguiente tiene algún impacto en la respuesta, pero mi plan es usar el patrón de repositorio y las clases POCO para que las referencias a las definiciones de tabla en el archivo .DBML sean locales para mi acceso a datos capa.

Gracias

Answer 1

que tendría que aconsejan su uso UNO archivo dbml para todas sus tablas.

Si está tratando de join two tables from different data contexts, hace que su código sea más intrincado. Se puede hacer por simulating cross context joins, pero ¿por qué ponerse en esa situación? Que sea simple estúpido.

Además, si decides ir con 2 o más archivos dbml y por error agregas la misma tabla a múltiples contextos de datos, obtendrás un "This member is defined more than once” error.

Answer 2

He trabajado en un proyecto donde el equipo decidió separar el dominio en cuatro archivos DBML diferentes. La razón principal de este spit-up tuvo que ver con el diseñador de LINQ to SQL. El diseñador no fue construido para ser utilizado con grandes dominios.

Estos cuatro 'subdominios' en este proyecto estaban razonablemente separados, pero hubo cierta superposición y esto nos mordió todo el tiempo. Con esta experiencia, te aconsejo que uses un único archivo DBML por dominio. Por lo general, tendrá un dominio por base de datos, por lo que esto significa un archivo DBML por base de datos.

Personalmente, estoy en contra del uso de TransactionScope en el código de producción (pero lo uso para las pruebas de integración todo el tiempo), pero esa es otra discusión. Sin embargo, cuando usted decide ir con varios archivos DBML, y tienen un caso de uso donde se necesita crear múltiples clases DataContext, puede ejecutar en la misma transacción, de la siguiente manera:

using (var con = new SqlConnection("constr")) 
{ 
    con.Open(); 
    using (var tran = con.BeginTransaction()) 
    { 
     using (var context = new CustomerDataContext(con)) 
     { 
      // do some work with it 
      context.SubmitChanges(); 
     } 

     using (var context = new VendorDataContext(con)) 
     { 
      // do some work with it 
      context.SubmitChanges(); 
     } 
    } 
} 

Este es el modelo Uso la mayoría de las veces, incluso con un solo DataContext. Sin embargo, la creación de la conexión y la transacción se abstraen, por lo que solo hay un lugar en el código donde se realiza la transacción.

Answer 3

Tengo un proyecto bastante grande con 200 tablas o menos y funciona bien en un contexto de datos; dado que todos los datos están bastante interconectados (diseñados entre la 2ª y la 3ª forma normal), sería un dolor utilizar contextos de datos múltiples.

Los problemas de contexto múltiple no serían divertidos en las áreas donde la aplicación necesita hacer una consulta en comparación con las tablas que están divididas; Debería asegurarse de que ciertas tablas estén en contextos de datos separados, independientemente de la forma en que LINQ funcione y la jerarquía descendente. Al menos desde un punto de vista práctico, no es que no se pueda hacer.

HTH.

Answer 4

Usaría un archivo DBML por contexto. Por contexto, me refiero a la operación requerida por su usuario ya que él/ella se encuentra en una ventana particular de su aplicación. Por ejemplo:

1. Usted tiene una interfaz gráfica de usuario que le permite administrar sus objetos de clientes; Luego consideraría tener un CustomerManagementDataContext dentro del cual agregaría las tablas para las tareas de administración de clientes relacionadas, y todas las dependencias.

De esta manera, es posible que tenga un contexto por ventana, si se entiende lo que quiero decir. Pero todo depende de su modelo relacional, esto podría ser más fácil para incluir todas las tablas en su archivo DBML, pero luego crea un contexto un poco más complicado y no señala las tablas relacionadas con la administración de su cliente o De lo contrario, según el contexto que construiste.

De hecho, para facilitar el uso, no es malo usar solo uno, pero esta no es una buena práctica, si se me permite mencionarlo.