database - A Linq to Sql-Varios archivos.DBML o un archivo.DBML

linq-to-sql .net-3.5

Question

Estoy trabajando en una aplicación web usando ASP.NET 3.5. La aplicación tiene cientos de tablas. En un seminario me dijeron que debería usar un archivo .DBML para toda la aplicación en lugar de usar varios 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 estoy mejor creando varios archivos .DBML que están agrupados lógicamente?

Por ejemplo, estaba pensando en crear los siguientes archivos .DBML:

• Cliente
• Vendedor
• Empleado
• Órdenes de venta

Una de las preocupaciones que tengo sobre el uso de múltiples archivos .DBML es cómo manejaría las actualizaciones en todos los archivos .DBML. Por ejemplo, si tuviera 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 tanto en el cliente como en los archivos .DBML de órdenes 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 de POCO para que las referencias a las definiciones de tabla en el archivo .DBML sean locales a mi capa de acceso a datos.

Gracias

Answer 1

Debería recomendarle que use UN archivo dbml para todas sus tablas.

Si intenta unir dos tablas de contextos de datos diferentes , hace que su código sea más complejo. Se puede hacer simulando uniones de contexto cruzado , pero ¿por qué ponerse en esa situación? Mantenlo simple, estúpido.

Además, si decide ir con 2 o más archivos dbml y agrega erróneamente la misma tabla a múltiples contextos de datos, obtendrá el error "Este miembro está definido más de una vez" .

Answer 2

He trabajado en un proyecto donde el equipo decidió separar el dominio en cuatro archivos DBML diferentes. La razón principal de esta escisión tuvo que ver con el diseñador 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 algunas coincidencias y esto nos mordió todo el tiempo. Con esta experiencia, te aconsejo que uses un solo 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 de usar TransactionScope en el código de producción (pero lo uso para pruebas de integración todo el tiempo), pero esa es otra discusión. Sin embargo, cuando decide utilizar varios archivos DBML y tiene un caso de uso en el que necesita crear varias clases de DataContext, puede ejecutarlas 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 que 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 más o menos y funciona bien en un contexto de datos; ya que todos los datos están bastante interconectados (diseñados entre la segunda y la tercera forma normal), sería un dolor utilizar múltiples contextos de datos.

Los múltiples problemas de contexto no serían divertidos en las áreas donde la aplicación necesita hacer una consulta en tablas divididas; tendría que asegurarse de que ciertas tablas estén en contextos de datos separados, independientemente de la forma en que LINQ funciona y de la jerarquía de desglose. Al menos desde el punto de vista de la conveniencia, no es que no se pueda hacer.

HTH.

Answer 4

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

1. Tiene una GUI que le permite administrar sus objetos de Cliente; Luego consideraría tener un CustomerManagementDataContext dentro del cual agregaría las tablas relacionadas con las tareas de administración de clientes y todas las dependencias.

De esta manera, puede tener un contexto por ventana, si ve lo que quiero decir. Pero todo depende de su modelo relacional, esto podría ser más fácil, ya que incluye 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 sus clientes o más, dependiendo del contexto que construyes.

De hecho, por facilidad de uso, no es malo usar solo uno, pero no es una buena práctica, si es que lo menciono.