Исследуем .NET 6. Часть 5. Поддержка EF Core в WebApplicationBuilder

Часть 1. ConfigurationManager
Часть 2. WebApplicationBuilder
Часть 3. Рассматриваем код WebApplicationBuilder
Часть 4. Создание конвейера промежуточного ПО в WebApplication

До сих пор в этой серии я рассматривал новые минимальные API хостинга, созданные с использованием WebApplication и WebApplicationBuilder. Они обеспечивают более простую модель для создания веб-приложений, сохраняя при этом те же общие функциональные возможности, что и приложения .NET Core 3.x/5 на основе универсального хоста.

Однако c этим упрощением есть проблемы. Более сложный код запуска в ранних версиях, обычно разделённый между Program.cs и Startup, имел преимущества, так как он предоставлял хорошо известные точки расширения (hooks), которые инструменты могли использовать для перехвата процесса запуска приложения.

Классическим примером этого является инструментарий EF Core^*EN. Если вы когда-либо использовали EF Core, возможно, вы знакомы с проблемами, возникающими при попытке изменить код запуска. А уж когда фреймворк меняет свой код запуска по умолчанию, понятно, что без проблем не обойтись!

Инструменты EF Core в ASP.NET Core 3.x/5

EF Core включает в себя различные инструменты для создания миграций и запуска их в вашей базе данных, но для этого ему необходимо понимать ваш код. По сути, он должен иметь возможность исполнять код запуска вашего приложения, чтобы использовать все настроенные вами сервисы конфигурации и внедрения зависимостей.

В предыдущих версиях ASP.NET Core EF Core подключался к методу CreateWebHostBuilder или CreateHostBuilder в вашем классе Program. Инструменты EF Core искали этот «волшебный» метод для получения доступа к IWebHostBuilder или IHostBuilder, используемый для создания вашего приложения.

public static IHostBuilder CreateHostBuilder(string[] args) =>
    Host.CreateDefaultBuilder(args)
        .ConfigureWebHostDefaults(webBuilder =>
        {
            webBuilder.UseStartup<Startup>();
        });

Это всегда казалось костылём; если вы переименуете метод или измените его сигнатуру, инструменты EF Core перестанут работать.

Используя этот хорошо известный метод, инструменты EF Core могут загрузить сборку вашего приложения с помощью рефлексии, выполнить метод, получить возвращённый IHostBuilder, вызвать на нем Build() для создания IHost, а затем получить IServiceProvider из свойства IHost.Services! И наконец, используя этот провайдер, проанализировать практически всё, что связано с вашим приложением. Довольно изящно, но сильно зависит от конкретных соглашений.

Так что же произошло, когда ASP.NET Core отказался от всех этих соглашений в .NET 6 с минимальными API хостинга? Ну, в общем, EF Core сломался^*EN