Linq-to-SQL：多少个数据上下文？

问题描述：

我有一个具有> 300个表的SQL Server 2008数据库。我必须设计的应用程序是Windows Forms应用程序，.NET 3.5，C＃。Linq-to-SQL：多少个数据上下文？

哪个是使用Linq-to-SQL最好的方法？

我打算为每个业务实*作一个数据上下文。

有什么问题吗？

我需要知道这种使用Linq-to-SQL的方式是否有缺点，或者可能会产生性能问题？

谢谢。

http://www.west-wind.com/weblog/posts/246222.aspx – Gregoire 2010-05-29 14:30:42

答

对于每个数据库，通常应该有一个单一的DBML文件（=数据上下文）。您当然不应该为每个业务实体创建DataContext，因为这样做会使您失去LINQ to SQL的大部分有用功能，如内存事务（工作单元），延迟加载以及对多个实体执行LINQ查询。

你有一个很大的模型（+300表），这意味着很多的实体。除了LINQ to SQL设计器之外，很多实体并不是一个大问题。使用这种大型模型的设计师可能会很烦人。这可能是在多个子域中分割域的原因（每个子域都有一个DBML文件），但当然不是每个实体都有一个。但是请记住，您在域的边界处丢失了L2S功能。

在过去，我建议一个团队将5个DBML文件中的+150实体域分割开来，将它们合并到一个DBML中。编辑模型的痛苦加剧了，但使用多个DataContext的痛苦消失了，这为他们大大降低了整体疼痛。

谢谢。请问，“编辑模型的痛苦”究竟是什么意思？我认为将子域中的大数据模型拆分可以解决一些性能问题。您是否具有在需要100多个并发用户的胜利表单/ SQL Server数据库中使用大数据模型/单个DBML文件的经验？谢谢。 – sh00 2010-05-30 08:24:11

您创建的数据上下文类的数量对性能无任何影响。 – 2010-05-30 11:45:54

我同意本。我无法想象有多个DBML对性能有任何影响。请解释你为什么这么想。 – Steven 2010-05-30 14:09:33

答

为每个业务实体创建数据上下文毫无意义，每个数据库只需要一个数据上下文。

答

好吧，这取决于有多少用户同时使用您的数据库，而不是有多少表。所以它关于典型的数据库问题：连接数，锁定和其他东西。

我不认为他在讨论实例化DataContext，而是为每个实体定义一个DBML文件。 – Steven 2010-05-29 15:56:27

是的，为每个实体定义一个DMBL文件。谢谢。 – sh00 2010-05-30 08:15:00

答

我现在使用1作为整个数据库，但有更多的合法用途。例如，我在安装连接到远程数据库的站点时运行脚本，并将数据导入并转换为新的部署格式。该过程使用一些临时表。

通过将临时表放入单独的上下文中，一旦部署了网站，我可以简单地删除这些上下文和代码，因为它们是独立的实体。