当使用单个用户帐户时，我注意到MVC的项目模板在当前Owin上下文（在中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);
看来这是要访问数据库的“身份”功能。我的理解是，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;
}
}
我认为如果这是标准做法，则实体框架对此会有一些支持，但是它只是在控制器级别创建了一个实例。是否可以安全地假设，如果DbContext仅从该控制器进行访问，那么它在功能上等同于上述实现，并且将其放置在Owin管道中是过大的？
我想这种方法的另一种用法是，如果需要其他设置，则是DbContext的单个初始化点。
DbContext设计为轻量级，因此每次需要一个新实例时都不会花费太多成本。主要成本是重新创建连接和垃圾回收所创建的所有实例。
请注意，如果您Find()在DbSet上使用该方法，它将缓存结果，因此下次您请求它时，它不需要进入数据库。如果重新使用相同的上下文，则可以利用该缓存，但是，如果创建新的上下文，则会丢失缓存。
如果将int存储DbContext在控制器的实例成员中，则它将仅用于一个请求，因为将为每个请求创建一个新的控制器实例。只要确保您不要将其放置在静态成员中，否则我希望您会获得各种竞赛条件。
本文收集自互联网，转载请注明来源。
如有侵权，请联系[email protected] 删除。
我来说两句