Создание DbContext во время разработки
Некоторые команды EF Core Tools (например, команды миграции ) требуют создания производного DbContext
экземпляра во время разработки для сбора сведений о типах сущностей приложения и их сопоставлении с схемой базы данных. В большинстве случаев рекомендуется DbContext
настроить таким образом, чтобы он был настроен во время выполнения.
Существуют различные способы создания DbContext
следующих средств:
Если в проекте запуска используется веб-узел ASP.NET Core или универсальный узел .NET Core, средства пытаются получить объект DbContext от поставщика услуг приложения.
Средства сначала пытаются получить поставщика услуг путем вызова, вызоваProgram.CreateHostBuilder()
Build()
, а затем доступа к свойствуServices
.
public class Program
{
public static void Main(string[] args)
=> CreateHostBuilder(args).Build().Run();
// EF Core uses this method at design time to access the DbContext
public static IHostBuilder CreateHostBuilder(string[] args)
=> Host.CreateDefaultBuilder(args)
.ConfigureWebHostDefaults(
webBuilder => webBuilder.UseStartup<Startup>());
}
public class Startup
{
public void ConfigureServices(IServiceCollection services)
=> services.AddDbContext<ApplicationDbContext>();
public void Configure(IApplicationBuilder app, IWebHostEnvironment env)
{
}
}
public class ApplicationDbContext : DbContext
{
public ApplicationDbContext(DbContextOptions<ApplicationDbContext> options)
: base(options)
{
}
}
Примечание
При создании нового приложения ASP.NET Core этот перехватчик включается по умолчанию.
Само DbContext
и все зависимости в конструкторе должны быть зарегистрированы в качестве служб в поставщике услуг приложения. Это можно легко достичь, имея конструктор на объектеDbContext
, который принимает экземпляр в качестве аргумента DbContextOptions<TContext>
и используя AddDbContext<TContext>
метод.
Если dbContext не удается получить от поставщика службы приложений, средства ищут производный DbContext
тип внутри проекта. Затем они пытаются создать экземпляр с помощью конструктора без параметров. Это может быть конструктор по умолчанию, если DbContext
он настроен с помощью OnConfiguring
метода.
Вы также можете рассказать инструментам, как создать DbContext, реализуя Microsoft.EntityFrameworkCore.Design.IDesignTimeDbContextFactory<TContext> интерфейс: если класс, реализующий этот интерфейс, найден в том же проекте, что и производный DbContext
или в проекте запуска приложения, средства обходя другие способы создания DbContext и использовать фабрику времени разработки.
public class BloggingContextFactory : IDesignTimeDbContextFactory<BloggingContext>
{
public BloggingContext CreateDbContext(string[] args)
{
var optionsBuilder = new DbContextOptionsBuilder<BloggingContext>();
optionsBuilder.UseSqlite("Data Source=blog.db");
return new BloggingContext(optionsBuilder.Options);
}
}
Фабрика времени разработки может быть особенно полезной, если необходимо настроить DbContext
время разработки по-разному, чем во время выполнения, если конструктор принимает дополнительные параметры, не зарегистрированы в di, если DbContext
вы не используете di вообще, или если по какой-то причине вы предпочитаете не иметь CreateHostBuilder
метод в классе приложения ASP.NET Core Main
.
Оба IDesignTimeDbContextFactory<TContext>.CreateDbContext и Program.CreateHostBuilder
примите аргументы командной строки.
Эти аргументы можно указать из средств:
dotnet ef database update -- --environment Production
Маркер --
направляет dotnet ef
для обработки всего следующего как аргумента и не пытается проанализировать их как параметры. Все дополнительные аргументы, не используемые dotnet ef
приложением, перенаправляются в приложение.
Отзыв о .NET
.NET — это проект с открытым исходным кодом. Выберите ссылку, чтобы оставить отзыв: