Création de DbContext au moment de la conception

  • Article

Certaines des commandes EF Core Tools (par exemple, les commandes Migrations) nécessitent la création d’une instance DbContext dérivée au moment de la conception afin de recueillir des détails sur les types d’entités de l’application et leur mappage à un schéma de base de données. Dans la plupart des cas, il est souhaitable que le DbContext créé soit configuré d’une manière semblable à celle de la configuration au moment de l’exécution.

Les outils essaient de créer de diverses manières DbContext :

À partir des services d’application

Si votre projet de démarrage utilise l’hôte web ASP.NET Core ou l’hôte générique .NET Core, les outils essaient d’obtenir l’objet DbContext auprès du fournisseur de services de l’application.

Les outils essaient d’abord d’obtenir le fournisseur en faisant appel à Program.CreateHostBuilder(), en appelant Build(), puis en accédant à la propriété 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)
    {
    }
}

Remarque

Ce hook est inclus par défaut lorsque vous créez une application ASP.NET Core.

Le DbContext et les dépendances de son constructeur doivent être inscrits en tant que services dans le fournisseur de services de l’application. Cela peut être facilement obtenu en ayant un constructeur sur le DbContext qui prend une instance de DbContextOptions<TContext> comme argument , à l’aide de la AddDbContext<TContext> méthode.

Utilisation d’un constructeur sans paramètre

Si le dbContext ne peut pas être obtenu à partir du fournisseur de services de l’application, les outils recherchent le type dérivé DbContext dans le projet. Ils essaient par la suite de créer une instance à l’aide d’un constructeur sans paramètre. Il peut s’agir du constructeur par défaut si le DbContext est configuré à l’aide de la méthode OnConfiguring.

À partir d’une fabrique au moment de la conception

Vous pouvez également indiquer aux outils comment créer votre DbContext en implémentant l’interface Microsoft.EntityFrameworkCore.Design.IDesignTimeDbContextFactory<TContext> : si une classe implémentant ladite interface se trouve dans le même projet que le projet dérivé DbContext (ou dans le projet de démarrage de l’application), les outils contournent les autres façons de créer dbContext et utilisent plutôt la fabrique au moment de la conception.

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

Une fabrique au moment de la conception peut être particulièrement utile si vous devez configurer DbContext différemment selon qu’il s’agit du moment de la conception ou du moment de l’exécution, si le constructeur DbContext accepte des paramètres supplémentaires ne sont pas enregistrés dans un DI, si vous n’utilisez absolument pas de DI, ou si, pour une raison quelconque, vous préférez ne pas avoir de méthode CreateHostBuilder dans la classe Main de votre application ASP.NET Core.

Args

IDesignTimeDbContextFactory<TContext>.CreateDbContext et Program.CreateHostBuilder acceptent les arguments de la ligne de commande.

Ces arguments peuvent être spécifiés à partir des outils :

dotnet ef database update -- --environment Production

Le jeton -- dirige dotnet ef pour traiter tout ce qui suit comme argument, sans essayer de les analyser en tant qu’options. Tous les arguments supplémentaires, non utilisés par dotnet ef, sont transférés à l’application.