为了在ASP.net 3.5应用程序中充分使用LinqTosql，有必要创建
DataContext
classes(通常使用VS 2008中的设计器完成)。从UI的角度来看，DataContext是您希望通过LinqTosql公开的数据库部分的设计，并且是设置LinqTosql的ORM功能的一部分。
我的问题是：我正在设置一个使用大型数据库的项目，其中所有表以某种方式通过外键互连。我的第一个倾向是创建一个庞大的DataContext类来建模整个数据库。这样我可以在理论上(虽然我不知道在实践中是否需要这样做)使用通过LinqTosql生成的外键连接很容易地在代码中的相关对象之间插入相关对象等。
然而，在给出一些想法之后，我现在认为创建多个DataContext类可能更有意义，每个类与我的数据库中的特定命名空间或逻辑相关部分相关。我的主要担心是实时化和处理一个巨大的DataContext类，用于与数据库的特定区域相关的单独操作会对应用程序资源造成不必要的影响。另外，创建和管理比一个大的DataContext文件更容易。我会失去的是，数据库的一些遥远的部分将不能通过LinqTosql导航(即使一连串的关系在实际数据库中连接)。另外，会有一些表类可以存在于多个DataContext中。
关于多个DataContexts(对应于DB命名空间)是否适合代替(或除了)一个非常大的DataContext类(对应于整个DB)的任何想法或经验？
解决方法
我不同意约翰的回答。 DataContext(或Linq to Entities ObjectContext)比连接更像是“工作单位”。它管理更改跟踪等。请参阅此博客文章以了解描述：
Lifetime of a LINQ to SQL DataContext
这篇博文的四个要点是DataContext：
>非常适合
为“工作单位”做法
>也是为了设计
“无状态”服务器操作
>不是为了设计
长期使用
>
Should be used very carefully after any SumbitChanges() operation.
考虑到，我不认为使用多个DataContext会造成任何损害 – 事实上，为不同类型的工作创建不同的DataContexts将有助于使您的LinqTosql更具可用性和组织性。唯一的缺点是您无法使用sqlMetal自动生成您的dmbl。
