在MVC中根据请求使用Owin DbContext的实体框架

Question

我注意到MVC的项目模板在使用单个用户帐户时会将一些对象放在当前的Owin上下文中(in App_Start/Startup.Auth.cs):

// Configure the db context, user manager and signin manager to use a single instance per request
app.CreatePerOwinContext(ApplicationDbContext.Create);
app.CreatePerOwinContext<ApplicationUserManager>(ApplicationUserManager.Create);
app.CreatePerOwinContext<ApplicationSignInManager>(ApplicationSignInManager.Create);

看起来这是访问数据库的Identity功能.我的理解是,ApplicationDbContext每个请求创建一个单个实例,并通过整个管道重新使用.用我自己的实体框架做同样的事情是否有益DbContext？

例如,我在以下位置创建了一个新文件App_Start/Startup.Data.cs:

public partial class Startup
{

    public void ConfigureData(IAppBuilder app)
    {

        app.CreatePerOwinContext(CreateParkingEntities);

    }

    protected ParkingEntities CreateParkingEntities()
    {
        return new ParkingEntities();
    }

}

然后在Startup.cs:

public partial class Startup
{
    public void Configuration(IAppBuilder app)
    {
        ConfigureAuth(app);
        ConfigureData(app);
    }
}

然后我可以在我的控制器中使用上下文:

private ParkingEntities _db;

public ParkingEntities DbContext
{
    get
    {
        return _db ?? HttpContext.GetOwinContext().Get<ParkingEntities>();
    }
    private set
    {
        _db = value;
    }
}

我认为如果这是标准做法,实体框架会有一些脚手架,但它只是在控制器级别创建一个实例.是否可以安全地假设if DbContext仅从该控制器访问,那么它在功能上等同于上述实现并将其置于Owin管道中是否过度杀伤？

我想如果需要额外的设置,这种方法的另一个用途是DbContext的单个初始化点.

Answer 1

DbContext被设计为轻量级的，因此每次需要时创建一个新实例的成本并不高。主要成本是重新创建连接和垃圾收集您正在创建的所有实例。

请注意，如果您Find()在 DbSets 上使用该方法，它将缓存结果，因此下次您请求它时，不需要访问数据库。如果重复使用相同的上下文，则可以利用该缓存，但如果创建新的上下文，则会丢失缓存。

如果将 存储DbContext在控制器的实例成员中，则它将仅用于一个请求，因为将为每个请求创建一个新的控制器实例。只要确保你不要将它放在静态成员中 - 我希望如果你这样做，你会得到各种竞争条件。