实际上,我从Blazor
和EF Core
开始。在注册DbContext
的时候,我被塞了起来。DbContext
可以通过AddDbContext
或AddDbContextFactory
注册。但是有什么区别呢?
builder.Services.AddDbContext<DataContext>(opt => opt.UseSqlServer("..."));
builder.Services.AddDbContextFactory<DataContext>(opt => opt.UseSqlServer("..."));
我从医生那里得到了以下信息:
AddDbContext
在使用依赖注入时使用此方法.Entity不支持在同一个Microsoft.EntityFrameworkCore.DbContext实例上运行的多个并行操作。这包括异步查询的并行执行和来自多个线程的任何显式并发使用。
AddDbContextFactory
在
应用程序和其他依赖注入作用域与上下文生存期不对齐的情况下,建议注册工厂.为了方便起见,此方法还将上下文类型本身注册为一个作用域服务。这允许从依赖项注入作用域(酌情由工厂直接或创建)解析上下文实例。
那么我们是否可以从全局上说,如果程序需要从不同的线程访问DbContext
,或者同时需要向AddDbContextFactory
注册上下文,因为当它被创建(例如在控制器中)时,生命周期被设置为作用域,所以每次我们都会得到一个新的DbContext
。
private readonly DataContext _dbContext;
public BlogController(IDbContextFactory<DataContext> dbFactory)
{
// Will be created as SCOPED DbContext?
_dbContext = dbFactory.CreateDbContext();
}
我还发现了一个类似的问题,here。在注册过程中,AddDbContext
和AddDbContextFactory
中的生存期被设置。或者我漏掉了什么。
所以我的问题一般是:
当使用AddDbContext
AddDbContextFactory
时,DbContextFactory
和AddDbContext
Blazor
项目?当DbContext
在scoped
生存期内创建时,
H 237F 238
发布于 2021-12-06 15:45:17
什么时候使用AddDbContextFactory而不是AddDbContext?
在Blazor中,始终使用DbContextFactory。但话虽如此,我相信会有一个例外!
DbContextFactory和AddDbContext与DbContext的寿命有什么不同?
DbContextFactory管理它的DBContexts的生命周期。应用“工作单位”原则和生命周期就是工作单位。如果直接将上下文添加到DI容器(例如使用AddDbContext
),那么它将在DI容器的生存期内存在。
,我是否应该在Blazor项目中一般使用DbContextFactory?
上面已经回答了
当在作用域生存期内创建
时,DbContext是否存在内存开销?
当然了。内存由未处理的对象使用。范围内的DbContext在DI容器的生存期内存在。在容器本身被销毁之前,不会对容器中的对象调用Dispose。这就是为什么您从不使用临时DbContexts。在销毁会话DI容器之前不会释放它们。
发布于 2021-12-06 15:35:48
前提:我们喜欢DbContext的生命周期尽可能短。
对于HTTP服务器应用程序,我们具有Requets/响应周期的范围。这是理想的,问题解决了:注入一个作用域的DbContext。
对于Blazor应用程序,就像WinForms和WPF一样,我们没有这样方便的Scopes。因此,我们必须更直接地管理DbContext。
您可以在IDisposable和/或OwningComponentBase中使用表单(Page)的生存期,但该生存期通常太长。
因此,负担转移到存储库(和/或服务):他们必须在每个方法的基础上管理DbContext。这就是DbContextFactory的作用所在:您可以简单地注入工厂,但每个方法看起来如下:
void DoSomething()
{
using (var ctx = _factory.CreateContext())
{
...
}
}
Blazor应用程序不会直接使用DbContext,所以上面的内容主要适用于Blazor。
https://stackoverflow.com/questions/70247235
复制相似问题