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对象之间共享数据或状态。

其余的多线程问题与数据库中的concurrency有关，而与线程操作无关。

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

Answer 2

你可以逃脱这个：

var repo = new EntityRepo();

entity = repo.GetEntity(12345);   

var related = entity.RelatedEntities;

请参阅this StackOverflow post以获取解释为什么不处理您的上下文不会导致连接泄漏或类似的事情。

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

修改：MSDN documents表示连接尽快打开并尽快关闭。因此，跳过使用不会导致连接池问题。

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

2 个答案: