多个DataContext类是否合适?

icum 发布于 2018-02-08 .net 最后更新 2018-02-08 01:08 783 浏览

为了在ASP.net 3.5应用程序中充分使用LinqToSql,需要创建DataContext classes(通常使用VS 2008中的设计器完成)。从UI的角度来看,DataContext是您希望通过LinqToSql公开的数据库部分的设计,并且是设置LinqToSql的ORM功能所必需的。 我的问题是:我正在建立一个使用大型数据库的项目,在这个数据库中,所有的表都以某种方式通过外键相互连接。我的第一个倾向是使一个巨大的DataContext类模拟整个数据库。这样,我可以理论上(虽然我不知道这是否需要在实践中)使用通过LinqToSql生成的外键连接轻松地在我的代码中的相关对象之间插入相关的对象,等等。 但是,在给出一些想法之后,我现在认为创建多个DataContext类可能更有意义,每个类都与我的数据库中的特定命名空间或逻辑相关部分有关。我主要关心的是,实例化和处理一个庞大的DataContext类,使得与数据库的特定区域相关的单个操作始终会对应用程序资源施加不必要的强制。此外,创建和管理较小的DataContext文件比一个大的文件更容易。我会失去的是,会有一些遥远的数据库部分,不能通过LinqToSql(即使在实际数据库中连接它们的关系链)导航。此外,还会有一些表类存在于多个DataContext中。 对于一个非常大的DataContext类(对应于整个数据库),是否有多个DataContext(对应于DB名称空间)是否合适(或者除此之外)的想法或经验?

已邀请:

aet

赞同来自:

在我使用LINQ to SQL和LINQ to Entities的经验中,DataContext与数据库的连接是同义的。所以,如果您要使用多个数据存储,则需要使用多个DataContext。我的直觉反应是你不会注意到包含大量表的DataContext的速度慢了很多。如果你这样做,你总是可以在逻辑上拆分数据库,在那里你可以隔离与其他表集没有任何关系的表,并创建多个上下文。

wrerum

赞同来自:

我一直在争论同一个问题,而在传统数据库上装饰LINQ to SQL。我们的数据库有点大(150表),经过一些思考和实验,我选择使用多个DataContext。这是否被认为是反模式还有待观察,但现在它使生活易于管理。

nvelit

赞同来自:

我不同意约翰的回答。 DataContext(或者Linq to Entities ObjectContext)比连接更像是一个“工作单元”。它管理更改跟踪等。请参阅此博客文章的描述: Lifetime of a LINQ to SQL DataContext 这篇博文的四个要点是DataContext:

  1. 非常适合 为“工作单元”方法
  2. 也是为了 “无状态”服务器操作
  3. 不适用于     长期使用
  4. Should be used very carefully after
    any SumbitChanges() operation.
    
考虑到这一点,我不认为使用多个DataContext会造成任何伤害 - 实际上,为不同类型的工作创建不同的DataContext将有助于使您的LinqToSql转换更加便于使用和组织。唯一的缺点是你不能使用sqlmetal来自动生成你的dmbl。

rquis

赞同来自:

我认为约翰是正确的。 “我主要担心的是,对于与数据库的特定区域相关的单个操作,实例化和处理一个巨大的DataContext类将会对应用程序资源施加不必要的强加” 你如何支持这种说法?什么是您的实验显示一个大的DataContext是一个性能瓶颈?拥有多个数据上下文很像有多个数据库,在类似的情况下也是有意义的,也就是说,很少。如果您正在使用多个数据上下文,则需要跟踪哪些对象属于哪个数据上下文,而且您无法关联不在同一数据上下文中的对象。这是一个昂贵的设计气味没有真正的好处。 @Evan“DataContext(或Linq to Entities ObjectContext)更像是一个”工作单元“而不是一个连接” 这就是为什么你不应该有多个数据上下文。为什么你一次要多一个“工作单位”呢?

uut

赞同来自:

我不同意接受的答案。在提出的问题中,系统有一个单一的大型数据库,几乎每个表(也是我工作的情况)之间都有很强的外键关系。在这种情况下,将其分解为更小的DataContext(DC)有两个直接的和主要的缺点(这两个问题都提到):

    您可以尝试明智地选择DC边界,但最终会遇到这样一种情况:在一个表中使用一个关系会非常方便DC到另一个表中,并且您将无法使用。 有些表可能出现在多个DC中。这意味着如果您想添加特定于表的辅助方法,业务逻辑或其他部分类中的代码,则这些类型将不会跨DC的。你可以通过从自己的特定基类继承每个实体类来解决这个问题。此外,架构更改将不得不在多个DC中重复。
现在这些是显着的缺点。有足够的优势来克服它们吗?这个问题提到性能:
My main concern is that instantiating and disposing one huge DataContext class all the time for individual operations that relate to specific areas of the Database would be impose an unnecessary imposition on application resources.
事实上,一个大型的DC在一个典型的工作单元中需要花费更多的时间来实例化或使用,这并不是事实。实际上,after the first instance is created in a running process, subsequent copies of the same DC can be created almost instantaneously。 对于具有彻底的外键关系的单个大型数据库来说,多个DC的唯一真正优势是可以更好地分隔代码。但是你已经可以用部分类来做到这一点。 而且,工作单位的概念与原来的问题并不相关。工作单元通常是指单个DC 实例 正在做的工作量,而不是一个DC class strong>