一个 Linq to Sql - 多个 .DBML 文件或一个 .DBML 文件

Posted 2023-02-22

【中文标题】一个 Linq to Sql - 多个 .DBML 文件或一个 .DBML 文件

【英文标题】：A Linq to Sql - Multiple .DBML files or one .DBML File

【发布时间】：2011-01-20 02:02:21

【问题描述】：

我正在使用 ASP.NET 3.5 开发一个 Web 应用程序。该应用程序有数百个表。在一次研讨会上有人告诉我，我应该为整个应用程序使用一个 .DBML 文件，而不是使用多个 .DBML 文件（*** 中也有一篇帖子说了同样的话）。鉴于我有这么多表，使用一个 .DBML 文件是否有意义，或者我最好创建多个逻辑分组的 .DBML 文件？

例如，我正在考虑创建以下 .DBML 文件：

客户 供应商 员工 销售订单

我对使用多个 .DBML 文件的担忧之一是如何处理跨 .DBML 文件的更新。例如，如果我在输入新的销售订单时必须更新客户表上的字段。我将如何处理？我当然不想在 Customer 和 Sales Order .DBML 文件中都包含 customer 表。我可以将操作包装在 TransactionScope 中吗？

我不知道以下是否对答案有任何影响，但我的计划是使用存储库模式和 POCO 类，以便对 .DBML 文件中的表定义的引用对我的数据访问层来说是本地的.

谢谢

【参考方案1】：

我不得不建议您对所有表使用 ONE dbml 文件。

如果您尝试join two tables from different data contexts，它会使您的代码更加复杂。可以通过simulating cross context joins 完成，但为什么要让自己陷入那种境地。保持简单愚蠢。

此外，如果您决定使用 2 个或更多 dbml 文件，并且错误地将同一个表添加到多个数据上下文中，那么您将收到 "This member is defined more than once” error。

【讨论】：

我忘了考虑跨 DBML 文件的连接问题。我只是希望.DBML 文件中有这么多表不会给我带来任何意外的悲伤。谢谢

【参考方案2】：

我参与过一个项目，团队决定将域分成四个不同的 DBML 文件。引发此问题的主要原因与 LINQ to SQL 设计器有关。设计器不是为大型域而构建的。

这个项目中的这四个“子域”是相当独立的，但有一些重叠，这一直困扰着我们。有了这个经验，我建议您为每个域使用一个 DBML 文件。通常每个数据库都有一个域，所以这意味着每个数据库有一个 DBML 文件。

就个人而言，我反对在生产代码中使用 TransactionScope（但我一直将它用于集成测试），但这是另一个讨论。但是，当您决定使用多个 DBML 文件，并且有一个需要创建多个 DataContext 类的用例时，您可以在同一个事务中运行它们，如下所示：

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();
        
    

这是我最常使用的模型，即使只有一个 DataContext。但是，连接和事务的创建被抽象掉了，所以在代码中只有一个地方进行事务。

【参考方案3】：

我有一个相当大的项目，大约有 200 个表，它在一个数据上下文中运行良好；由于所有数据都是相互关联的（设计在第 2 范式和第 3 范式之间），因此使用多个数据上下文会很痛苦。

在应用程序需要对拆分的表进行查询的区域中，多上下文问题不会很有趣；由于 LINQ 的工作方式和向下钻取层次结构，您必须确保某些表位于单独的数据上下文中。至少从方便的角度来看，并不是说做不到。

HTH。

【参考方案4】：

我会在每个上下文中使用一个 DBML 文件。就上下文而言，我的意思是您的用户需要完成的操作，因为她/他在您的应用程序的一个特定窗口中。例如：

您有一个 GUI 允许您管理您的客户对象； 然后，我会考虑使用 CustomerManagementDataContext，在其中添加与客户管理任务相关的表以及所有依赖项。

这样，如果你明白我的意思，你可以在每个窗口都有一个上下文。但这一切都取决于您的关系模型，这可能更容易将所有表包含到您的 DBML 文件中，但是，它确实创建了一个更复杂的上下文，并且没有指出与您的客户管理相关的表或否则，取决于您构建的上下文。

确实，为了方便使用，只使用一个也不错，但如果我可以提及的话，这不是一个好的做法。

【讨论】：

#1 指的是什么？有链接吗？