logo标签列表

一个 Linq to Sql - 多个 .DBML 文件还是一个 .DBML 文件

databaselinq-to-sql.net-3.5
29
我正在使用ASP.NET 3.5开发一个Web应用程序，该应用程序有数百个数据表。在研讨会上，我被告知应该使用一个.DBML文件来代替使用多个.DBML文件来处理整个应用程序（stackoverflow上也有一篇帖子说了同样的事情）。考虑到我有这么多表，使用一个.DBML文件是否合理，还是最好创建逻辑分组的多个.DBML文件呢？
例如，我考虑创建以下.DBML文件：
  • Customer
  • Vendor
  • Employee
  • Sales Order
使用多个.DBML文件的一个问题是如何跨.DBML文件进行更新。例如，在输入新销售订单时，如果我必须更新客户表中的字段，我该怎么办？我肯定不想在客户和销售订单.DBML文件中都包含客户表。我能否将操作包装在TransactionScope中？
我不知道以下内容是否对答案有任何影响，但我的计划是使用存储库模式和POCO类，以便对.DBML文件中的表定义的引用将局限于我的数据访问层。
谢谢
4个回答
11
我忘记考虑跨DBML文件的连接问题。我只希望在.DBML文件中有这么多表不会引起任何意外的烦恼。 - mikener
6

我曾经参与过一个项目，团队决定将域分成四个不同的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。然而，连接和事务的创建已被抽象化处理，所以在代码中只有一个地方进行事务处理。

2
我有一个相当大的项目，大约有200个表，在一个数据上下文中运行良好；由于所有数据都相互关联（设计在第二和第三范式之间），如果使用多个数据上下文，将会很麻烦。
在应用程序需要对拆分的表进行查询的区域中，多个上下文问题将不会很有趣；由于LINQ的工作方式和钻取层次结构，您必须确保某些表格在单独的数据上下文中，至少从方便的角度来看，虽然这是可行的，但并不容易。
希望对您有所帮助。
0

我会为每个上下文使用一个DBML文件。所谓的上下文是指用户在应用程序的一个特定窗口中执行的操作。例如：

  1. 您拥有一个GUI，可让您管理客户对象；然后我将考虑在其中添加与客户管理任务相关的CustomerManagementDataContext，并添加所有依赖表。

这样，如果您明白我的意思，您可以针对每个窗口拥有一个上下文。但是，这完全取决于您的关系模型，这可能更容易地将所有表包含在您的DBML文件中，但这会创建一个更加复杂的上下文，并且不会指出与您构建的上下文相关的表或其他内容。

实际上，为了方便使用，只使用一个并不是坏习惯，但如果我提到它，这不是好做法。

那个#1是指什么？你有链接吗？ - Justin
网页内容由stack overflow 提供, 点击上面的
可以查看英文原文，
原文链接