我有一个项目,有许多不同的类在一组通用的表中查询和修改数据.我已经设置了一个.dbml文件,它为我们提供了一个DataContext类.我的问题是,是否应该由所有对象使用DataContext的单个实例,或者是否可以安全使用多个实例.我也想知道单个DataContext的线程安全性,以及是否应同步访问它的方法.
Rick Strahl有一篇关于你的选择的好文章:http://www.west-wind.com/weblog/posts/246222.aspx.
另请参阅:LINQ to SQL - 您的DataContext在哪里?.
对于每种类型的部署,您可能需要略微不同的策略 - Web,桌面,Windows服务......
总结一下,您的选择是:
Global DataContext - 在多线程环境(包括Web应用程序)中很危险.请记住,实例成员不保证是线程安全的(来自Bradley Grainger 上面的回答).
每个线程的DataContext - 复杂.如果您的DataContext正在跟踪更改,则必须确保在适当的时间刷新它们.实例化,存储和检索DataContext是一件痛苦的事.
每个原子操作的DataContext - 您失去了跟踪更改的能力,因为一个DataContext创建一个对象而另一个DataContext更新或删除它.将数据对象附加到新的DataContext可能无法按预期工作.
每个数据对象的DataContext - 似乎不够优雅,因为您必须在实例化(创建和附加)和更新/删除(将其从数据对象中拉出并使用它)上与DataContext大惊小怪.
我为每个数据对象选择了一个DataContext.它可能不是最好的解决方案,但它适用于所有部署环境.
我为每个事务使用一个新的DataContext实例.
重用旧实例可能很麻烦,并且会使DataContext的内容膨胀,因为必须跟踪任何在某个时间加载的项目 - 您的应用程序将变得越来越慢,内存膨胀.
如果您需要的项目长于事务,则可以通过克隆项目将其与DataContext分离,然后可以使用Attach()将其重新附加到新的DataContext.
我甚至可以克隆一个项目,通过网络通过WCF发送它,稍后再调用它,将它附加到一个新的DataContext并保存更改(当然我需要一个时间戳列).
DataContext类足够轻量级,您可以反复实例化它.这使得在单个方法中访问实体对象时更简单.如果您需要从不同的类和方法访问相同的LINQ对象,同时将它们连接到DataContext以进行跟踪,那么保留单个实例也是可以的.