我正在使用ASP.NET 3.5开发Web应用程序。该应用程序有数百个表。我在研讨会上被告知我应该为整个应用程序使用一个.DBML文件,而不是使用多个.DBML文件(stackoverflow中也有一个帖子说同样的事情)。鉴于我有这么多表使用一个.DBML文件是有意义的还是我最好创建逻辑分组的多个.DBML文件?
例如,我正在考虑创建以下.DBML文件:
我对使用多个.DBML文件的一个担忧是如何处理.DBML文件的更新。例如,如果在输入新的销售订单时我必须更新客户表上的字段。我该怎么处理?我当然不希望在Customer和Sales Order .DBML文件中包含customer表。我可以在TransactionScope中包装操作吗?
我不知道以下是否对答案有任何影响,但我的计划是使用存储库模式和POCO类,以便.DBML文件中对表定义的引用对我的数据访问层是本地的。
由于
答案 0 :(得分:11)
我必须建议您为所有表使用 ONE dbml文件。
如果您尝试join two tables from different data contexts,则会使您的代码更加复杂。它可以由simulating cross context joins完成,但为什么要让自己处于这种情况。保持简单愚蠢。
此外,如果您决定使用2个或更多dbml文件,并且错误地将同一个表添加到多个数据上下文,那么您将获得"This member is defined more than once” error。
答案 1 :(得分: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 :(得分:2)
我有一个相当大的项目,有200个左右的表,它可以在一个数据上下文中正常工作;由于所有数据都是相互关联的(在第二和第三范式之间设计),因此使用多个数据上下文会很痛苦。
在应用程序需要对拆分的表进行查询的区域中,多个上下文问题不会很有趣;由于LINQ的工作方式和向下钻取的层次结构,您必须确保某些表位于不同的数据上下文中。至少从方便的角度来看,并非无法做到。
HTH。
答案 3 :(得分:0)
我会在每个上下文中使用一个DBML文件。根据上下文,我的意思是您的用户需要在您的应用程序的某个特定窗口中执行操作。例如:
- 您有一个GUI,允许您管理您的Customer对象; 然后,我会考虑使用CustomerManagementDataContext,在其中我将为相关的客户管理任务和所有依赖项添加表。
醇>
这样,如果你看到我的意思,你可以在每个窗口中有一个上下文。但这一切都取决于您的关系模型,这可能更容易将所有表包含到您的DBML文件中,但是,它确实创建了一个更复杂的上下文,并没有指出与您的客户管理相关的表或否则,取决于你建立的背景。
事实上,为了便于使用,仅使用一个也不错,但如果我提及的话,这不是一个好的做法。