Criação de DbContext no tempo de design

  • Artigo

Alguns dos comandos das Ferramentas do EF Core (por exemplo, os comandos de Migrações) exigem que uma instância DbContext derivada seja criada em tempo de design para coletar detalhes sobre os tipos de entidade do aplicativo e como eles são mapeados para um esquema de banco de dados. Na maioria dos casos, é desejável que o DbContext criado seja configurado de maneira semelhante à forma como ele seria configurado no runtime.

Há várias maneiras pelas quais as ferramentas tentam criar o DbContext:

De serviços de aplicativos

Se o projeto de inicialização usar o host Web do ASP.NET Core ou o Host Genérico do .NET Core, as ferramentas tentarão obter o objeto DbContext do provedor de serviços do aplicativo.

As ferramentas primeiro tentam obter o provedor de serviços invocando Program.CreateHostBuilder(), chamando Build() e, em seguida, acessando a propriedade 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)
    {
    }
}

Observação

Quando você cria um novo aplicativo ASP.NET Core, esse gancho é incluído por padrão.

O próprio DbContext e quaisquer dependências em seu construtor precisam ser registrados como serviços no provedor de serviços do aplicativo. Isso pode ser facilmente alcançado tendo um construtor no DbContext que usa uma instância de DbContextOptions<TContext> como argumento e usando o AddDbContext<TContext> método.

Como usar um construtor sem parâmetros

Se o DbContext não puder ser obtido do provedor de serviços de aplicativo, as ferramentas procurarão o tipo derivado DbContext dentro do projeto. Em seguida, eles tentam criar uma instância usando um construtor sem parâmetros. Esse pode ser o construtor padrão se o DbContext estiver configurado usando o método OnConfiguring.

De uma fábrica de tempo de design

Você também pode informar às ferramentas como criar seu DbContext implementando a interface Microsoft.EntityFrameworkCore.Design.IDesignTimeDbContextFactory<TContext>: se uma classe que implementa essa interface for encontrada no mesmo projeto que o derivado DbContext ou no projeto de inicialização do aplicativo, as ferramentas ignorarão as outras maneiras de criar o DbContext e usarão a fábrica de tempo de design.

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);
    }
}

Uma fábrica de tempo de design pode ser especialmente útil se você precisar configurar o DbContext do tempo de design de forma diferente do que no runtime, se o construtor DbContext tiver parâmetros adicionais que não estejam registrados em DI, se você não estiver usando DI ou se, por algum motivo, preferir não ter um método CreateHostBuilder na classe Main do aplicativo ASP.NET Core.

Args

IDesignTimeDbContextFactory<TContext>.CreateDbContext e Program.CreateHostBuilder aceitam argumentos de linha de comando.

Você pode especificar esses argumentos das ferramentas:

dotnet ef database update -- --environment Production

O token -- direciona dotnet ef para tratar tudo o que se segue como um argumento e não tentar analisá-los como opções. Todos os argumentos extras não usados por dotnet ef são encaminhados para o aplicativo.