Partilhar via

Criação de DbContext em tempo de design

Alguns dos comandos do EF Core Tools (por exemplo, os comandos Migrations ) exigem que uma instância derivada DbContext seja criada em tempo de design para reunir 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 assim criado seja configurado de forma semelhante à forma como seria configurado em tempo de execução.

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

Dos serviços de aplicativos

Se seu projeto de inicialização usa o ASP.NET Core Web Host ou o .NET Core Generic Host, as ferramentas tentam 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 Services propriedade.

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

Note

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

O DbContext próprio 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 por ter um construtor no DbContext que toma uma instância de DbContextOptions<TContext> como um argumento e usando o AddDbContext<TContext> método.

Usando 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. Este pode ser o construtor padrão se o DbContext é configurado usando o OnConfiguring método.

De uma fábrica em tempo de design

Você também pode dizer às ferramentas como criar seu DbContext implementando a Microsoft.EntityFrameworkCore.Design.IDesignTimeDbContextFactory<TContext> interface: 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 em tempo de design pode ser especialmente útil se você precisar configurar o diferente para o DbContext tempo de projeto do que em tempo de execução, se o DbContext construtor tomar parâmetros adicionais não estão registrados em DI, se você não estiver usando DI em tudo, ou se, por algum motivo, você preferir não ter um CreateHostBuilder método na classe do Main seu aplicativo ASP.NET Core.

Args

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

Você pode especificar esses argumentos a partir das ferramentas:

dotnet ef database update -- --environment Production

O token -- direciona dotnet ef a 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.

  • Last updated on