Linq to SQL - 我应该如何管理数据库请求？

Question

我对 DataContext 的生命周期进行了一些研究，试图找出最好的做事方式。

鉴于我想在 Web 应用程序中重复使用 DAL，我决定采用DataContext Per Business Object Request 方法。

我的想法是从 dbml 文件扩展我的 L2S 实体，以检索数据库的信息，为每个请求创建一个单独的上下文，例如，

public partial class AnEntity
{
    public IEnumerable<RelatedEntity> GetRelatedEntities()
    {
        using (var dc = new MyDataContext())
        {
            return dc.RelatedEntities.Where(r => r.EntityID == this.ID);
        }
    }
}

在返回实体方面...我此时需要返回 POCO 还是可以简单地返回从查询返回的业务对象？我知道，如果我尝试访问返回实体的属性（在 DataContext 被释放之后），它将失败。然而，这就是我决定实现这些类型的方法的原因，例如

而不是：

AnEntity entity = null;
using (var repo = new EntityRepo())
{
    entity = repo.GetEntity(12345);   
}
var related = entity.RelatedEntities; // this would cause an exception

理论上我应该能够做到：

AnEntity entity = null;
using (var repo = new EntityRepo())
{
    entity = repo.GetEntity(12345);   
}
var related = entity.GetRelatedEntities();

鉴于我的特定应用程序的情况（需要在 Windows 服务和 Web 应用程序中工作），我会我想知道这是否是一种合理的方法，是否存在明显的缺陷，以及对于我正在尝试做的事情是否有更好的方法。

谢谢。

Answer 1

一般来说，只要您不使用多个线程调用单个 DataContext 对象，就应该没问题。换句话说，每个线程使用一个 DataContext 对象，并且不要在不同的 DataContext 对象之间共享数据或状态。

其余的多线程问题与数据库中的并发有关，不是线程操作。

除了这些警告之外，你的方法似乎是合理的。您可以使用分部类来实现业务方法，也可以在 Linq to SQL 类和存储库之间添加业务层。

Answer 2

您可以摆脱这个：

var repo = new EntityRepo();

entity = repo.GetEntity(12345);   

var related = entity.RelatedEntities;

请参阅此 StackOverflow 帖子解释为什么不处理你的上下文不会导致连接泄漏或类似的事情。

当存储库和上下文获取的实体超出范围时（构建网站时，在请求结束时），垃圾收集器将清理存储库和上下文。

编辑：MSDN文档连接是尽可能晚开门，尽快关门。因此跳过使用不会导致连接池问题。