多个DataContext类是否合适？

Question

为了在ASP.net 3.5应用程序中完全使用LinqToSql,有必要创建DataContext 类(通常使用VS 2008中的设计器完成).从UI的角度来看,DataContext是您希望通过LinqToSql公开的数据库部分的设计,并且是设置LinqToSql的ORM功能所不可或缺的.

我的问题是:我正在建立一个使用大型数据库的项目,其中所有表都通过外键以某种方式互连.我的第一个倾向是创建一个巨大的DataContext类来模拟整个数据库.这样我理论上可以(虽然我不知道在实践中是否需要这样)使用通过LinqToSql生成的外键连接,可以轻松地在我的代码中的相关对象之间进行切换,插入相关对象等.

但是,在考虑之后,我现在认为创建多个DataContext类可能更有意义,每个类与我的数据库中的特定命名空间或逻辑相关部分相关.我主要担心的是,对于与数据库的特定区域相关的单个操作,实例化和处理一个巨大的DataContext类将对应用程序资源施加不必要的强制.此外,创建和管理较小的DataContext文件比一个大文件更容易.我将失去的是,数据库的某些远程部分无法通过LinqToSql导航(即使一系列关系在实际数据库中连接它们).此外,还有一些表类存在于多个DataContext中.

有关多个DataContexts(对应于DB名称空间)是否适合代替(或除了)一个非常大的DataContext类(对应于整个DB)的任何想法或经验？

Answer 1

我不同意约翰的回答.DataContext(或Linq to Entities ObjectContext)更像是一个"工作单元"而不是连接.它管理变更跟踪等.有关说明,请参阅此博客文章:

LINQ to SQL DataContext的生命周期

这篇博文的四个要点是DataContext:

1. 非常适合"工作单元"方法
2. 也是为"无状态"服务器操作而设计的
3. 不适合长期使用

4. Should be used very carefully after
   any SumbitChanges() operation.
   

考虑到这一点,我不认为使用多个DataContext会造成任何伤害 - 事实上,为不同类型的工作创建不同的DataContexts将有助于使您的LinqToSql更加可用和有组织.唯一的缺点是你将无法使用sqlmetal自动生成你的dmbl.

Answer 2

我一直在争论相同的问题,同时在旧版数据库上复制LINQ to SQL.我们的数据库有点大(150个表),经过一些思考和实验,我选择使用多个DataContexts.这是否被视为反模式仍有待观察,但现在它使生活变得可管理.