Entity Framework Core

Article
08/24/2023

Entity Framework (EF) Core est une version légère, extensible, open source et multiplateforme de la très connue technologie d’accès aux données Entity Framework.

EF Core peut servir de mappeur objet-relationnel (O/RM), qui :

Permet aux développeurs .NET de travailler avec une base de données à l’aide d’objets .NET.
Élimine la nécessité d’une grande partie du code d’accès aux données qui doit généralement être écrit.

EF Core prend en charge de nombreux moteurs de base de données ; consultez Fournisseurs de base de données pour plus d’informations.

Modèle

Avec EF Core, l’accès aux données est effectué à l’aide d’un modèle. Un modèle est constitué de classes d’entité et d’un objet de contexte qui représente une session avec la base de données. L’objet de contexte permet l’interrogation et l’enregistrement des données. Pour plus d’informations, consultez Création d’un modèle.

EF prend en charge les approches de développement de modèles suivantes :

Générez un modèle à partir d’une base de données existante.
Codez manuellement un modèle pour correspondre à la base de données.
Une fois qu’un modèle est créé, utilisez EF Migrations pour créer une base de données à partir du modèle. Les migrations permettent d’évoluer la base de données au fur et à mesure que le modèle change.

using System.Collections.Generic;
using Microsoft.EntityFrameworkCore;

namespace Intro;

public class BloggingContext : DbContext
{
    public DbSet<Blog> Blogs { get; set; }
    public DbSet<Post> Posts { get; set; }

    protected override void OnConfiguring(DbContextOptionsBuilder optionsBuilder)
    {
        optionsBuilder.UseSqlServer(
            @"Server=(localdb)\mssqllocaldb;Database=Blogging;Trusted_Connection=True;ConnectRetryCount=0");
    }
}

public class Blog
{
    public int BlogId { get; set; }
    public string Url { get; set; }
    public int Rating { get; set; }
    public List<Post> Posts { get; set; }
}

public class Post
{
    public int PostId { get; set; }
    public string Title { get; set; }
    public string Content { get; set; }

    public int BlogId { get; set; }
    public Blog Blog { get; set; }
}

Interrogation

Les instances de vos classes d’entité sont récupérées de la base de données à l’aide de LINQ (Language Integrated Query). Pour plus d’informations, consultez Interrogation des données.

using (var db = new BloggingContext())
{
    var blogs = db.Blogs
        .Where(b => b.Rating > 3)
        .OrderBy(b => b.Url)
        .ToList();
}

Enregistrement des données

Les données sont créées, supprimées et modifiées dans la base de données à l’aide d’instances de vos classes d’entité. Pour en savoir plus, consultez Enregistrement de données.

using (var db = new BloggingContext())
{
    var blog = new Blog { Url = "http://sample.com" };
    db.Blogs.Add(blog);
    db.SaveChanges();
}

Considérations relatives à EF O/RM

Bien qu’EF Core soit bon pour résumer de nombreux détails de programmation, il existe certaines bonnes pratiques applicables à n’importe quelle O/RM qui permettent d’éviter les pièges courants dans les applications de production :

Les connaissances de niveau intermédiaire ou supérieure du serveur de base de données sous-jacent sont essentielles pour architecter, déboguer, profiler et migrer des données dans des applications de production hautes performances. Par exemple, connaissance des clés primaires et étrangères, contraintes, index, normalisation, instructions DML et DDL, types de données, profilage, etc.
Test fonctionnel et d’intégration : il est important de répliquer l’environnement de production aussi étroitement que possible pour :
- Recherchez des problèmes dans l’application qui s’affichent uniquement lors de l’utilisation d’une version ou d’une édition spécifique du serveur de base de données.
- Interceptez les modifications cassants lors de la mise à niveau d’EF Core et d’autres dépendances. Par exemple, l’ajout ou la mise à niveau de frameworks tels que ASP.NET Core, OData ou AutoMapper. Ces dépendances peuvent affecter EF Core de manière inattendue.
Tests de performances et de stress avec des charges représentatives. L’utilisation naïve de certaines fonctionnalités n’est pas bien mise à l’échelle. Par exemple, plusieurs collections incluent, une utilisation intensive du chargement différé, des requêtes conditionnelles sur des colonnes non indexées, des mises à jour massives et des insertions avec des valeurs générées par le magasin, un manque de gestion de la concurrence, des modèles volumineux, une stratégie de cache insuffisante.
Révision de sécurité : par exemple, gestion des chaînes de connexion et d’autres secrets, autorisations de base de données pour l’opération non-déploiement, validation d’entrée pour SQL brut, chiffrement pour les données sensibles. Consultez les flux d’authentification sécurisés pour la configuration sécurisée et le flux d’authentification.
Assurez-vous que la journalisation et les diagnostics sont suffisants et utilisables. Par exemple, la configuration de journalisation appropriée, les balises de requête et Application Insights.
Récupération d’erreur. Préparez des urgences pour les scénarios d’échec courants tels que la restauration de version, les serveurs de secours, l’équilibrage de charge et le scale-out, l’atténuation DoS et les sauvegardes de données.
Déploiement et migration d'applications. Planifier la façon dont les migrations vont être appliquées pendant le déploiement; le fait de le faire au démarrage de l’application peut souffrir de problèmes d’accès concurrentiel et nécessite des autorisations plus élevées que nécessaire pour l’opération normale. Utilisez la préproduction pour faciliter la récupération des erreurs irrécupérables lors de la migration. Pour plus d'informations, consultez Application de migrations.
Examen détaillé et test des migrations générées. Les migrations doivent être soigneusement testées avant d’être appliquées aux données de production. La forme du schéma et les types de colonnes ne peuvent pas être facilement modifiés une fois que les tables contiennent des données de production. Par exemple, sur SQL Server, nvarchar(max) et decimal(18, 2) sont rarement les meilleurs types pour les colonnes mappées aux propriétés de chaîne et décimales, mais ce sont les valeurs par défaut utilisées par EF, car il n’a pas connaissance de votre scénario spécifique.

Étapes suivantes

Pour des tutoriels d’introduction, consultez Bien démarrer avec Entity Framework Core.

Partager via