ASP.NET Core Blazor avec Entity Framework Core (EF Core)

Cet article explique comment utiliser Entity Framework Core (EF Core) dans les applications Blazor côté serveur.

Blazor côté serveur est un framework d’application avec état. L’application maintient une connexion continue au serveur, et l’état de l’utilisateur est conservé dans la mémoire du serveur dans un circuit. Des données conservées dans des instances de service d’injection de dépendances qui sont limitées au circuit constituent un exemple d’état utilisateur. Le modèle d’application unique fourni par Blazor nécessite une approche spéciale pour utiliser Entity Framework Core.

Remarque

Cet article aborde EF Core dans les applications Blazor côté serveur. Les applications Blazor WebAssembly s’exécutent dans un bac à sable (sandbox) WebAssembly qui empêche la plupart des connexions de base de données directes. L’exécution d’EF Core dans Blazor WebAssembly n’entre pas dans le cadre de cet article.

Cette aide s’applique aux composants qui adoptent le rendu côté serveur interactif (SSR interactif) dans une Blazor Web App.

Flux d’authentification sécurisé requis pour les applications de production

Cet article utilise une base de données locale qui ne nécessite pas l’authentification des utilisateurs. Les applications de production doivent utiliser le flux d’authentification le plus sécurisé disponible. Pour plus d’informations sur l’authentification pour les applications de test et de production Blazor déployées, consultez les articles dans le nœud Sécurité et Identity Blazor.

Pour les services Microsoft Azure, nous vous recommandons d’utiliser des identités managées. Les identités managées offrent un moyen sécurisé de s’authentifier auprès des services Azure sans stocker d’informations d’identification dans le code de l’application. Pour plus d’informations, consultez les ressources suivantes :

• Que sont les identités managées pour les ressources Azure ? (Documentation Microsoft Entra)
• Documentation sur les services Azure
  • Identités managées dans Microsoft Entra pour Azure SQL
  • Guide pratique pour utiliser des identités managées avec App Service et Azure Functions

Exemple d’application

L’exemple d’application a été généré comme référence pour les applications Blazor côté serveur qui utilisent EF Core. L’exemple d’application inclut une grille avec des opérations de tri et de filtrage, de suppression, d’ajout et de mise à jour.

L’exemple illustre l’utilisation d’EF Core pour gérer l’accès concurrentiel optimiste. Toutefois, les jetons d’accès concurrentiel générés par une base de données native ne sont pas pris en charge pour les bases de données SQLite, qui est le fournisseur de base de données pour l’exemple d’application. Pour illustrer la concurrence avec l’exemple d’application, adoptez un autre fournisseur de base de données qui prend en charge les jetons d’accès concurrentiel générés par la base de données (par exemple, le fournisseur SQL Server).

Voir ou télécharger un exemple de code (Comment télécharger) : sélectionnez le dossier qui correspond à la version de .NET que vous adoptez. Dans le dossier de la version, accédez à l’exemple nommé BlazorWebAppEFCore.

L’exemple utilise une base de données SQLite locale afin qu’elle puisse être utilisée sur n’importe quelle plateforme. L’exemple configure également la journalisation de la base de données pour afficher les requêtes SQL qui sont générées. Cette fonctionnalité est configurée dans appsettings.Development.json :

{
  "DetailedErrors": true,
  "Logging": {
    "LogLevel": {
      "Default": "Information",
      "Microsoft.AspNetCore": "Warning",
      "Microsoft.Hosting.Lifetime": "Information",
      "Microsoft.EntityFrameworkCore.Database.Command": "Information"
    }
  }
}

Les composants de grille, d’ajout et d’affichage utilisent le modèle « contexte par opération », où un contexte est créé pour chaque opération. Le composant d’édition utilise le modèle « contexte par composant », où un contexte est créé pour chaque composant.

Remarque

Certains des exemples de code de cette rubrique nécessitent des espaces de noms et des services qui ne sont pas affichés. Pour inspecter le code entièrement opérationnel, ce qui inclut les directives @using et @inject requises pour des exemples Razor, consultez l’exemple d’application.

Créer un didacticiel sur l’application Blazor de base de données de films

Pour obtenir une expérience de didacticiel qui crée une application qui utilise EF Core pour travailler avec une base de données, consultez Créer une Blazor application de base de données vidéo (Vue d’ensemble). Le tutoriel vous montre comment créer un Blazor Web App qui peut afficher et gérer des films dans une base de données de films.

Accès aux bases de données

EF Core s’appuie sur un DbContext comme moyen de configurer l’accès à la base de données et d’agir comme une unité de travail. EF Core fournit l’extension AddDbContext pour les applications ASP.NET Core qui inscrit le contexte en tant que service avec étendue. Dans les applications Blazor côté serveur, les inscriptions de service délimité peuvent être problématiques, car l’instance est partagée entre les composants du circuit de l’utilisateur. DbContext n’est pas thread-safe et n’est pas conçu pour une utilisation simultanée. Les durées de vie existantes sont inappropriées pour les raisons suivantes :

• Singleton partage l’état entre tous les utilisateurs de l’application et conduit à une utilisation simultanée inappropriée.
• Délimité (valeur par défaut) pose un problème similaire entre les composants pour le même utilisateur.
• Temporaire entraîne la création d’une instance par requête. Toutefois, comme les composants peuvent être de longue durée, il en résulte un contexte d’une plus longue durée que prévu.

Les recommandations suivantes sont conçues pour fournir une approche cohérente de l’utilisation d’EF Core dans les applications Blazor côté serveur.

• Envisagez d’utiliser un seul contexte par opération. Le contexte est conçu pour une instanciation rapide et à faible charge :

  using var context = new MyContext();
  
  return await context.MyEntities.ToListAsync();
  

• Utilisez un indicateur pour empêcher plusieurs opérations simultanées :

  if (Loading)
  {
      return;
  }
  
  try
  {
      Loading = true;
  
      ...
  }
  finally
  {
      Loading = false;
  }
  

  Placez les opérations après la ligne Loading = true; dans le bloc try.

  La logique de chargement ne nécessite pas de verrouillage des enregistrements de la base de données, car la cohérence des threads n’est pas un problème. La logique de chargement est utilisée pour désactiver les contrôles d’interface utilisateur afin que les utilisateurs ne sélectionnent pas par inadvertance des boutons ou ne mettent pas à jour les champs pendant la récupération de données.

• S’il est possible que plusieurs threads accèdent au même bloc de code, injectez une fabrique et créez une nouvelle instance par opération. Autrement, l’injection et l’utilisation du contexte sont généralement suffisantes.

• Pour les opérations de plus longue durée qui tirent parti du suivi des modifications ou du contrôle d’accès concurrentiel, d’EF Core, limitez le contexte à la durée de vie du composant.

Nouvelles instances DbContext

Le moyen le plus rapide de créer une instance DbContext consiste à utiliser new. Toutefois, certains scénarios nécessitent la résolution de dépendances supplémentaires :

• Utilisation d’DbContextOptions pour configurer le contexte.
• Utilisation d’une chaîne de connexion par DbContext, comme lorsque vous utilisez le modèle Identity d’ASP.NET Core. Pour plus d’informations, consultez Architecture multilocataire (documentation EF Core).

Avertissement

Ne stockez pas les secrets d’application, les chaîne de connexion, les informations d’identification, les mots de passe, les numéros d’identification personnels (PIN), le code C#/.NET privé ou les clés/jetons privés dans le code côté client, qui est toujours non sécurisé. Dans les environnements de test/intermédiaire et de production, le code côté Blazor serveur et les API web doivent utiliser des flux d’authentification sécurisés qui évitent de conserver les informations d’identification dans le code du projet ou les fichiers de configuration. En dehors des tests de développement locaux, nous vous recommandons d’éviter l’utilisation de variables d’environnement pour stocker des données sensibles, car les variables d’environnement ne sont pas l’approche la plus sécurisée. Pour les tests de développement locaux, l’outil Secret Manager est recommandé pour sécuriser les données sensibles. Pour plus d’informations, consultez Gestion sécurisée des données sensibles et des informations d’identification.

L’approche recommandée pour créer un DbContext avec des dépendances consiste à utiliser une fabrique. EF Core 5.0 ou version ultérieure fournit une fabrique intégrée pour la création de contextes.

L’exemple suivant configure SQLite et active la journalisation des données. Le code utilise une méthode d’extension (AddDbContextFactory) afin de configurer la fabrique de base de données pour l’injection de dépendances et de fournir des options par défaut :

builder.Services.AddDbContextFactory<ContactContext>(opt =>
    opt.UseSqlite($"Data Source={nameof(ContactContext.ContactsDb)}.db"));

La fabrique est injectée dans les composants et est utilisée pour créer des instances DbContext.

Sur la page home de l’exemple d’application, IDbContextFactory<ContactContext> est injecté dans le composant :

@inject IDbContextFactory<ContactContext> DbFactory

Un DbContext est créé à l’aide de la fabrique (DbFactory) pour supprimer un contact dans la méthode DeleteContactAsync :

private async Task DeleteContactAsync()
{
    using var context = DbFactory.CreateDbContext();
    Filters.Loading = true;

    if (Wrapper is not null && context.Contacts is not null)
    {
        var contact = await context.Contacts
            .FirstAsync(c => c.Id == Wrapper.DeleteRequestId);

        if (contact is not null)
        {
            context.Contacts?.Remove(contact);
            await context.SaveChangesAsync();
        }
    }

    Filters.Loading = false;

    await ReloadAsync();
}

Remarque

Filters est un IContactFilters injecté et Wrapper est une référence de composant au composant GridWrapper. Consultez le composant Home (Components/Pages/Home.razor) dans l’exemple d’application.

Délimiter à la durée de vie du composant

Vous pouvez souhaiter créer un DbContext qui existe pendant toute la durée de vie d’un composant. Cela vous permet de l’utiliser comme unité de travail et de tirer parti des fonctionnalités intégrées, telles que le suivi des modifications et la résolution de l’accès concurrentiel.

Vous pouvez utiliser la fabrique pour créer un contexte et le suivre pendant la durée de vie du composant. Commencez par implémenter IDisposable et injectez la fabrique comme indiqué dans le composant EditContact (Components/Pages/EditContact.razor) :

@implements IDisposable
@inject IDbContextFactory<ContactContext> DbFactory

L’exemple d’application garantit que le contexte est supprimé lorsque le composant est supprimé :

public void Dispose() => Context?.Dispose();

Enfin, OnInitializedAsync est remplacé pour créer un nouveau contexte. Dans l’exemple d’application, OnInitializedAsync charge le contact dans la même méthode :

protected override async Task OnInitializedAsync()
{
    Busy = true;

    try
    {
        Context = DbFactory.CreateDbContext();

        if (Context is not null && Context.Contacts is not null)
        {
            var contact = await Context.Contacts.SingleOrDefaultAsync(c => c.Id == ContactId);

            if (contact is not null)
            {
                Contact = contact;
            }
        }
    }
    finally
    {
        Busy = false;
    }
}

Activer la journalisation des données sensibles

EnableSensitiveDataLogging inclut les données d’application dans les messages d’exception et la journalisation d’infrastructure. Les données journalisées peuvent inclure les valeurs attribuées aux propriétés des instances d’entité et les valeurs de paramètres pour les commandes envoyées à la base de données. La journalisation des données avec EnableSensitiveDataLogging présente un risque de sécurité, car elle peut exposer des mots de passe et d’autres Informations d’identification personnelle (PII) lors de la journalisation d’instructions SQL exécutées sur la base de données.

Nous vous recommandons d’activer EnableSensitiveDataLogging uniquement pour le développement et le test :

#if DEBUG
    services.AddDbContextFactory<ContactContext>(opt =>
        opt.UseSqlite($"Data Source={nameof(ContactContext.ContactsDb)}.db")
        .EnableSensitiveDataLogging());
#else
    services.AddDbContextFactory<ContactContext>(opt =>
        opt.UseSqlite($"Data Source={nameof(ContactContext.ContactsDb)}.db"));
#endif

Ressources supplémentaires

• Documentation EF Core
• Blazor exemples de référentiel GitHub (dotnet/blazor-samples)
• BlazorArticles du nœud Sécurité et Identity