Мне нужна помощь, чтобы найти хорошее решение для внедрения DBContext в Repository Services

Я видел, что лучшие практики говорят, что я должен использовать IDbContextFactory

Это не «лучшая практика», на самом деле в данном случае это проблема.

Фактическая проблема, которую необходимо решить, заключается в том, что областью внедрения зависимостей в приложении Blazor Server является весь сеанс пользователя. Доступно множество вариантов если нам нужна семантика области видимости, и специализированная фабрика — только один из них. На самом деле DbContextFactory предназначен только для создания управляемых пользователем экземпляров DbContext. Он не предназначен для управления временем жизни оболочек или зависимых объектов.

DbContextFactory — управляемая пользователем область

DbContextFactory предназначен для использования, когда мы хотим явно управлять областью действия только DbContext, например, на функциональном уровне. Он только создает DbContext, но не удаляет его. Это видно из примеров документации:

@inject IDbContextFactory<ContactContext> DbFactory

private async Task DeleteContactAsync()
{
    using var context = DbFactory.CreateDbContext();
    ...
}

Это делает его плохо подходящим для CrmFirmsPersistenceService. По крайней мере, вызывающие службы должны явно удалять службу, чтобы она, в свою очередь, могла удалять экземпляр DbContext.

Объем компонента

Один из способов решить эту проблему — ограничить область действия службы временем жизни компонента. Это можно сделать, наследуя от OwningComponentBase.

В этом примере документации AppDbContext относится к сроку службы компонента. Он доступен через свойство Service:

@page "/users"
@attribute [Authorize]
@inherits OwningComponentBase<AppDbContext>

<h1>Users (@Service.Users.Count())</h1>

<ul>
    @foreach (var user in Service.Users)
    {
        <li>@user.UserName</li>
    }
</ul>

В случае вопроса это будет работать, не требуя фабрики контекста или активатора, просто зарегистрировав DbContexts и CrmFirmsPersistenceService и др. в качестве служб с ограниченной областью действия.

Конфигурация DI может быть:

services.AddDbContext<MyDBContext>(options => options.UseSqlServer(connectionString));
services.AddAutoMapper(Assembly.GetExecutingAssembly());
services.AddScoped<ICrmFirmsPersistenceService, CrmFirmsPersistenceService>();

Сам компонент должен был бы наследоваться от OwningComponentBase<T>

@page "/firms"
@inherits OwningComponentBase<ICrmFirmsPersistenceService>

<h1>Firms (@page.count)</h1>

<ul>
    @foreach (var firm in page.firms)
    {
        ...
    }
</ul>

@code {

    (IEnumerable<CrmFirmDTO> firms, int count) page = null!;
    protected override async Task OnInitializedAsync()
    {
        page = await Service.GetFirmsWithPagination();
    }

Явная область

Когда мы хотим определить более точную область, нам нужно создать ее явно с помощью IServiceProvider.CreateScope и создать службы, используя эту область. Вот как singleton Hosted Services может потреблять услуги с заданной областью.

Для этого нам нужно добавить IServiceProvider в качестве зависимости к компоненту:

@page "/firms"
@inject IServiceProvider Services

Затем, когда нам нужно создать экземпляр с областью действия ICrmFirmsPersistenceService, нам нужно сделать это через явную область:

using var scope=Services.CreateScope();
var firmsService=scope.GetRequiredService<ICrmFirmsPersistenceService>();
...

Когда эта область удаляется, любая обслуживаемая область, созданная с ее помощью, также будет удалена, включая CrmFirmsPersistenceService и его DbContext.