ASP.NET Web API 2 + Entity Framework 连接缓存的最佳实践答案

【问题标题】：ASP.NET WebAPI 2 + Entity Framework Best Practice for connection cachingASP.NET Web API 2 + Entity Framework 连接缓存的最佳实践
【发布时间】：2017-07-19 21:50:11
【问题描述】：

我正在尝试找出使用 WebAPI 和实体框架在我的平台上执行操作的最佳方式。

现在我正在为每个请求创建一个新连接：在每个控制器中，都有一个为每个类似方法实例化和处置的对象。

public class SchedulerController : ApiController
{
    private ApplicationDbContext db = new ApplicationDbContext();

    protected override void Dispose(bool disposing)
    {
        if (disposing)
            db.Dispose();
        base.Dispose(disposing);
    }
}

在我看来，为每个请求创建连接是影响性能的完全开销。我知道在 Java 上有一些工具（可能是胡桃夹子？）可以处理一种连接池以重用相同的连接并通过这种方式提高性能。

c# / ASP.NET / Azure 平台有类似的东西吗？

我也非常感谢请求增长数量的性能比较。

编辑：这主要是指 DbContext 自己进行的缓存。

【问题讨论】：

创建新的 DbContext 不会打开任何数据库连接

标签： c# asp.net entity-framework azure asp.net-web-api

【解决方案1】：

我认为您误解了实体框架的工作原理。

EF 在幕后使用 ADO.NET，因此连接池实际上由提供程序管理。您可以通过连接字符串更改池的行为。我相信它默认会重用连接。

EF 还在内部使用了一些模式，例如工作单元，因此它旨在封装一组操作（因此名称中使用了“上下文”一词）。这就是为什么您有一个 SaveChanges() 方法可以将所有内容“提交”到数据库的原因。

因此，实际上建议您为每个请求创建一个新实例，以保证“工作单元”的完整性，即使如此，您也应该确保以一种转换为的方式保存您的更改数据库方面的原子事务。

但是，您可以做的是仅在需要时创建实例，而不是让控制器在每次请求时创建它。再说一次，如果您使用 Web API，您几乎总是需要访问数据，所以...

【讨论】：