保持LINQ-to-SQL DataContext打开多长时间？

Question

我是linq-to-sql（和sql）的新手，我已经开始收集证据，证明我可能没有以正确的方式做事，所以我想看看你们都有什么说。

在我的员工分配应用程序中，我允许用户在员工和项目之间创建任务。在应用程序开始时，我打开了一个linq-to-sql数据上下文到我的管理数据库。在整个计划中，我从不放弃数据上下文。事实上，大多数表单构造函数都将此数据上下文作为其参数之一。

我有点认为这是做事的方式，直到我阅读另一个SO问题，其中提问者正在讨论在整个程序中重复创建数据上下文，然后根据需要将实体“附加”到新的数据上下文中。这将帮助我解决我遇到的问题，其中的事情正在“潜入”我的数据库。

那么你会在哪里使用第一种风格（并且不要羞于说永远），你会在哪里使用第二种风格？

Answer 1

如果您在ASP.NET MVC或Web服务中编写Web应用程序，则每次都会重新创建DataContext，因为应用程序在页面GET和POST之间是“无状态的”。

如果您正在编写Winforms或WPF应用程序，您可以以相同的方式执行此操作，尽管保持DataContext打开可以更容易，因为Winforms应用程序是有状态的（即您有一个容器可以存活DataContext）。

通常，每次需要完成"unit of work."时打开DataContext可能是明智的.DataContext本身相当轻量级，因此为每个“事务”打开一个并不是什么大不了的事。这种做法也与企业应用程序中的软件层（即数据库，DAL，服务层，存储库等）一致，并有助于在必要层之间强制分离关注点。

Answer 2

通常建议的做法是为每个原子操作创建一个新的DataContext。实际上，DataContext实际上非常便宜，并且非常适合快速周转。

作为一般经验法则，我倾向于实例化一个DataContext，执行一个CRUD操作，然后再次处理它。这可以是更新单个实体，也可以插入一堆对象。做任何对你的场景最有意义的事情。

如果您要从上下文传递实体，请小心，因为如果您尝试枚举或检索相关数据将抛出异常 - 最好将LINQ实体转换为独立对象（例如，Person LINQ）实体可以转换为PersonResult，由解决方案的逻辑层使用。）

希望有所帮助！