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

Question

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

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

• 客户
• 供应商
• 员工
• 销售订单

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

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

谢谢

Answer 1

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

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

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

Answer 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。但是，连接和事务的创建被抽象掉了，所以在代码中只有一个地方进行事务。

Answer 3

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

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

HTH。

Answer 4

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

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

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

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