Linq to SQL:每个页面都有一个小的DataContext好还是一个全局的好?

有联系的 可以 需要跨数据上下文进行查询,不要将它们分开。

但是请注意,DataContext应该是短期的——它们是工作单元模式的实现,因此它们的生命周期应该等于一个逻辑操作(例如加载一组产品或插入一个新订单)。数据上下文的创建和销毁成本很低,所以不要因为需要而浪费时间缓存它们。

本页 http://www.albahari.com/nutshell/10linqmyths.aspx

我相信数据上下文是非常轻量级的,主要是容器。在查询数据之前,数据不会实际加载到上下文中。我不认为拥有一个单一的数据上下文是错误的,而只是根据需要(作为一个工作单元)实例化它,而不是一直保持它。这样,你就不会有一个长寿命的物体会继续变得越来越大。

如果您的表可以被划分为相关的表组,那么您可能需要考虑为这些组中的每一个拥有单独的数据上下文。我不确定LINQ将如何使用来自多个上下文的数据处理查询,但似乎只要表位于同一服务器上,它就应该工作。如果确实将内容分解为多个上下文,并且查询需要来自多个上下文的表,则必须检查此项。

我在我们的数据库上做了一个测试,它有大约600个表。首先,我将它们分为9个离散的数据上下文,每个上下文都非常易于管理。然后,我编写了一个脚本,对其中一个进行了数百次选择、更新和删除(在每次访问之后都处理datacontext,这样LINQ就必须为每次访问重新创建datacontext)。

然后我制作了另一个datacontext,上面有所有600个表,并运行了相同的测试。