我目前正在为应用程序编写数据访问层。访问层广泛使用linq类来返回数据。当前,为了将数据反映回数据库,我添加了一个私有数据上下文成员和一个公共保存方法。代码看起来像这样:
private DataContext myDb; public static MyClass GetMyClassById(int id) { DataContext db = new DataContext(); MyClass result = (from item in db.MyClasss where item.id == id select item).Single(); result.myDb = db; return result; } public void Save() { db.SubmitChanges(); }
简而言之,这简直就是毛骨悚然,但这给出了总体思路。有没有更好的方法来处理这种模式?我是否想在每次访问数据库时实例化一个新的数据上下文?
实际上并不重要。不久前,我问了LINQ to SQL团队的Matt Warren,这是答复:
我们实现IDisposable的原因有几个: 如果应用程序逻辑需要保留实体,而不是预期使用DataContext或有效时,则可以通过调用Dispose强制执行该合同。该实体中的延迟加载程序仍将引用DataContext,并且如果有任何代码尝试导航延迟属性,则将尝试使用它。这些尝试将失败。Dispose还强制DataContext转储其物化实体的缓存,以便单个缓存的实体不会意外地使通过该DataContext物化的所有实体保持活动状态,否则将导致似乎是内存泄漏的情况。 可以欺骗自动关闭DataContext连接的逻辑,使连接保持打开状态。DataContext依靠应用程序代码枚举查询的所有结果,因为到达结果集的末尾会触发连接关闭。如果应用程序使用IEnumerable的MoveNext方法而不是C#或VB中的foreach语句,则可以过早退出枚举。如果您的应用程序遇到连接无法关闭的问题,并且怀疑自动关闭行为不起作用,则可以使用Dispose模式来解决。
我们实现IDisposable的原因有几个:
如果应用程序逻辑需要保留实体,而不是预期使用DataContext或有效时,则可以通过调用Dispose强制执行该合同。该实体中的延迟加载程序仍将引用DataContext,并且如果有任何代码尝试导航延迟属性,则将尝试使用它。这些尝试将失败。Dispose还强制DataContext转储其物化实体的缓存,以便单个缓存的实体不会意外地使通过该DataContext物化的所有实体保持活动状态,否则将导致似乎是内存泄漏的情况。
可以欺骗自动关闭DataContext连接的逻辑,使连接保持打开状态。DataContext依靠应用程序代码枚举查询的所有结果,因为到达结果集的末尾会触发连接关闭。如果应用程序使用IEnumerable的MoveNext方法而不是C#或VB中的foreach语句,则可以过早退出枚举。如果您的应用程序遇到连接无法关闭的问题,并且怀疑自动关闭行为不起作用,则可以使用Dispose模式来解决。
但是基本上,在大多数情况下,您并不需要 真正 丢弃它们- 这是设计使然。我个人比较喜欢这样做反正,因为它更容易遵循“一切处置其实现IDisposable”,而不是记住异常的负载,以它的规则- 但你不可能泄漏的资源,如果你 不 忘记处置它。