Asp.net mvc 为什么ASP.NET MVC WebAPI模板使用DbContext作为成员变量？

如果您在Visual Studio 2013中创建WebAPI/MVC项目，请添加模型和DbContext类，以及此模型的控制器，如下所述-

,

它创建一个将DbContext声明为成员变量的控制器，根据许多stackoverflow answers/online arcticles的说法，这是一个坏主意——就像这样

VisualStudio生成的控制器方法-

// GET: api/Authors
public IQueryable<Author> GetAuthors()
{
    return db.Authors;
}

如果使用建议的每个请求生存期，则将不起作用-

// GET: api/Authors
    public IQueryable<Author> GetAuthors()
    {
        DbSet<Author> authors = null;
        using(MyContext db = new MyContext) {
             authors = db.Authors;
        }
        return authors;
    }

因为当结果被迭代时，上下文已超出范围，并且您得到一个对象处理异常

那么，正确的方法是什么？如果是使用每个请求的方法，为什么VS模板使用成员变量方法？

原因在于这是一个简单的起点

使用ASP.NET MVC很容易理解和入门

将DbContext作为在控制器级别创建的成员变量并没有什么错，尽管它可能并不理想。随着应用程序变得越来越复杂，它就不能很好地适应

[…]根据许多答案/在线文章，这是个坏主意

我根本没有从你链接的答案中得到这一点

说明单个DbContext（即全局或每个线程的上下文）是错误的

如果使用建议的每个请求生存期，则将不起作用

这不是每个请求的生存期。这几乎就像是一个工作单元模式，但你没有用它做任何事情

你要做的事情的解决办法是

// GET: api/Authors
public IEnumerable<Author> GetAuthors()
{
    IEnumerable<Author> authors = null;

    using(MyContext db = new MyContext())
    {
         authors = db.Authors.ToList();
    }

    return authors;
}

在我看来，正确的处理方法是在DbContext中使用每个web请求的生活方式

---

在这里显示完整的示例可能有点长，超出了问题的范围。

回答很好，已接受，谢谢。ex中的成员变量让我感到困扰的是，它就像是在您离开action方法的范围以实际获得结果之后使用的。此外，许多repository/uow示例只是将repository/uow类作为控制器的成员变量。我觉得repository/uow类也应该在每个操作方法的using语句中汇总。。。也许是相同的区别。我想我同意你的看法。我刚刚创建了Web API服务，并倾向于为每个方法创建DbContext实例。。。让我们通过监控工具来了解这种方法是否存在任何问题。