【发布时间】:2019-04-17 07:25:16
【问题描述】:
我正在使用带有 Pomelo.EntityFramework.MySql 的 ASP.NET Core 2.2。
这是我的代码:
services.AddDbContext<dbContext>(options => options.UseMySQL(appConfigsSection["DbConnectionString"]));
services.AddSingleton<IUserService, UserService>();
services.AddAuthentication(x =>
{
x.DefaultAuthenticateScheme = JwtBearerDefaults.AuthenticationScheme;
x.DefaultChallengeScheme = JwtBearerDefaults.AuthenticationScheme;
})
.AddJwtBearer(x=> {
x.Events = new JwtBearerEvents
{
OnTokenValidated = context =>
{
var userService = context.HttpContext.RequestServices.GetRequiredService<IUserService>();
}
};
这是错误:
asp.net core 不能使用单例的作用域服务
就行了:
var userService = context.HttpContext.RequestServices.GetRequiredService<IUserService>();
我的理解是DBContext应该作为Singleton服务使用,IUserService也是。 但似乎 DBContext 被视为 Scoped Service。
我可以通过将 IUserService 切换回 Scoped Service 轻松修复它。但我想知道为什么我不能将 DBContext 用作单一服务?
我认为 DBContext 应该用作 Singleton 服务,对吗?
【问题讨论】:
-
是什么让你认为
DbContext应该是单身? -
绝对不。即使范围可能太大了。 DbContext 就像一个 NHibernate 会话 - 瞬态、单用户并且本质上是断开连接的,它不应该在必要时保持活动状态。就像连接一样,由于连接池,创建或关闭并不昂贵。就像连接一样,如果它存在的时间过长,它就会积累变化。如果它的连接保持打开的时间过长,它会积累锁,导致数据库阻塞并可能出现死锁。
-
鉴于 DbContext 的断开特性,caches 也会发生变化,就像 DataTable 一样,这意味着它不能被不同的线程/用户使用。所有这些都不是限制,因为它们使 DbContext fast 和 scalable。
-
一个有意义的问题是
why scoped instead of transient?在 Web 请求期间,如果代码多次请求相同的上下文,则将所有对象和更改缓存到请求结束,然后通过在最后一次调用SaveChanges将它们保存一次是有意义的。这将比在同一个请求期间执行例如 4 个方法更好,创建一个新的 CustomersContext 上下文来检索和修改 same 客户,然后保存更改 4 次,可能会覆盖彼此的更改
标签: c# entity-framework asp.net-core entity-framework-core