Les modèles avec Entity Framework Core

Introduction

Depuis toujours, le développeur a besoin de lire les données d’une base, écrire des enregistrements, supprimer des lignes, gérer des transactions, mettre à jour des données utilisateurs… Le framework .NET dispose depuis ses tout débuts d’une API permettant de communiquer avec une base de données et d’envoyer des requêtes à cette dernière. Cependant, cela peut vite devenir fastidieux et non maintenable. En effet, les erreurs de frappe sont courantes, et la gestion de toutes les requêtes SQL peut vite devenir une usine à gaz.

Microsoft développe depuis des années maintenant une brique logicielle permettant de faciliter l’accès à une base de données : Entity Framework. Ce framework est un ORM (Object-Relational Mapping), c’est-à-dire un outil qui permet de travailler avec des objets C# plutôt qu’avec des requêtes en dur. Le développeur va ainsi gérer, requêter, ajouter ou supprimer des objets via l’ORM, et ce dernier va automatiquement s’occuper de traduire les opérations via des requêtes SQL.

La dernière version d’Entity Framework, la version Core, est une réécriture complète des anciennes versions. Ce choix a été opéré dans le but d’améliorer tout d’abord...

Les différents providers de base de données

Tout d’abord, avant d’utiliser un ORM, il est important de savoir quel type de base de données il supporte. Entity Framework Core étant tout jeune, il ne supporte que les bases SQL Server et SQLite pour l’instant (avril 2016). Il supporte également les bases dites in-memory, c’est-à-dire stockées en mémoire, mais ce genre de base de données est plutôt utilisé pour effectuer des tests. Le but du projet est de couvrir à terme un maximum de bases de données. Dans le cadre des providers de base de données, les namespaces importants sont :

L’accès aux bases de données est devenu bien plus modulaire qu’avant, et permet ainsi d’embarquer, dans les applications web, uniquement ce dont le développeur a besoin. De plus, avec une architecture découplée, il sera bien plus facile par la suite d’ajouter de nouveaux providers pour d’autres types de bases de données (MySQL, Oracle…), ce qui était...

Les migrations

Avant de parler de migration, il est important de comprendre pourquoi Entity Framework Core ne supporte plus les Database Project et les EDMX. Ce type de projet permettait de construire un modèle relationnel, dans Visual Studio, en fonction des besoins du projet. Ce modèle était ensuite appliqué à la base de données, et dans un même temps les classes C# constituant les modèles étaient générées et tout de suite utilisables par le développeur.

Sur le papier, ce processus semble profitable à la propreté du projet, mais il n’en est rien. Il devient même contre-productif dans le cadre d’un projet très conséquent (lorsqu’on atteint la centaine de modèles). En effet, ce genre de procédé utilise un fichier XML comme référence afin de gérer le modèle de base de données, et son utilisation devient problématique quand il est partagé dans une équipe de développement car les modifications deviennent trop lourdes à gérer pour le gestionnaire de code source. Le projet est ainsi susceptible de perdre des informations sur le modèle de données, ce qui n’est pas acceptable dans un contexte professionnel.

La solution choisie par l’équipe de Microsoft est d’arrêter purement et simplement le support de ce type de projet. À la place, les experts de l’équipe préconisent l’utilisation d’une approche Code First. Déjà intégrée dans le framework depuis la version 4.1, cette approche est centrée autour des classes C# que les développeurs auront créées dans le projet. Le but de ces classes est de représenter la base de données sous forme de modèle objet compréhensible ensuite par l’ORM, qui sera capable d’interpréter automatiquement les mappings, les clés étrangères… L’utilisation d’attributs est également possible afin d’aider l’ORM à mieux s’en sortir, ou pour spécifier des mappings bien spécifiques, mais ce n’est pas l’objet de cette section.

L’avantage de cette approche est sa simplicité de mise en œuvre et de maintenance...

L’API Fluent

L’approche Code First est un excellent moyen de concevoir un modèle de données à la fois maintenable et flexible. Cependant, il existe forcément des cas dans un projet où le mapping doit être explicite plutôt qu’implicite.

Il existe deux possibilités pour déclarer un mapping spécifique :

Nous allons nous concentrer uniquement sur l’API Fluent dans ce chapitre car c’est la partie d’Entity Framework qui a subi le plus de changements.

L’API Fluent permet de coder les relations entre les entités. Cela veut dire que le développeur va utiliser des méthodes d’extensions, fournies par le framework, pour mapper le modèle à la base de données et définir les clés primaires, clés étrangères... L’API est contenue dans le namespace EntityFrameworkCore.Relational.

Prenons un exemple simple qui consiste à mapper une entité à une table qui ne porte pas le même nom. Dans un premier temps, il faut savoir que le mapping s’effectue dans un DbContext, et précisément dans la méthode OnModelCreating. Cette méthode reçoit un objet de type ModelBuilder, et c’est cet objet qui va permettre d’agir sur le mapping.

class MyContext : DbContext 
    { 
        public DbSet<Blog> Blogs { get; set; } 
 
        protected override void OnModelCreating(ModelBuilder 
modelBuilder) 
        { 
            modelBuilder.Entity<Blog>() 
                .ToTable("blogs"); 
        } 
    } ...

L’intégration d’Entity Framework Core

Entity Framework Core offre au développeur un système de configuration poussé lui permettant de personnaliser ses DbContext de manière extensible. En effet, ce sont les différents providers qui vont venir rajouter leurs propres options au système de configuration de base. Dans l’exemple de SQLite, c’est le namespace Microsoft.EntityFrameworkCore.Sqlite qui va venir rajouter la méthode UseSqlite afin de configurer l’accès à la base SQLite.

services.AddEntityFramework() 
    .AddSqlite() 
    .AddDbContext<BloggingContext>(options => 
        options.UseSqlite("Filename=./blog.db")); 

L’appel de cette méthode se fait dans la classe Startup, qui va ainsi contenir toute la configuration du contexte d’accès à la base de données pour chacun des appels. Ensuite, la méthode AddDbContext va simplement enregistrer le DbContext comme étant un service utilisable dans toute l’application via l’injection de dépendances.

Les contrôleurs sont un bon exemple d’utilisation du DbContext. L’injection de dépendances permet d’injecter ce service dans le constructeur, et ainsi rendre disponible l’accès à la base de données dans toutes les actions du contrôleur.

public MyController(BloggingContext context) 

La validation des modèles

Lorsqu’un utilisateur manipule l’application web afin de créer ou modifier un enregistrement, le formulaire utilisé va indiquer à l’utilisateur certaines informations de formatage afin d’assurer le bon traitement des données créées ou modifiées. Les exemples sont nombreux :

Ces contraintes doivent être respectées pour prévenir des potentielles failles de sécurité et vérifier que les données respectent bien certaines règles avant d’être insérées en base de données. Avec un modèle MVC, la validation peut se faire à la fois côté client (avec jQuery par exemple) et côté serveur (avec du C#).

Le framework .NET a abstrait toute cette mécanique de validation au travers d’attributs de validation. Ces derniers s’appliquent sur les modèles objets C# de l’application, ils embarquent de la logique métier afin de réduire la duplication de code et sont interprétables côté client et serveur pour valider les données. Les contraintes peuvent varier, allant de règles simples de champ requis, jusqu’à des patterns de validation plus complexes, comme pour les cartes de crédit, les numéros de téléphone ou les e-mails.

L’exemple ci-dessous montre l’application de quelques-uns de ces attributs provenant du namespace System.ComponentModel.DataAnnotations.

    public class Movie 
    { 
        public int Id { get; set; } 
 
        [Required] 
        [StringLength(100)] 
        public string Title { get; set; } 
 
        [Required] 
        [Range(0, 999.99)] 
        public float Price { get; set; } 
    } 

Les attributs sont très parlants, et permettent d’avoir...

Les patterns et antipatterns

Afin de bien utiliser Entity Framework, il est important de comprendre comment fonctionne l’ORM, mais aussi de bien l’utiliser. Il existe bon nombre de moyens de configurer Entity Framework au sein d’un projet ASP.NET Core, et nous allons expliciter dans cette section quelques bonnes et mauvaises pratiques pour aider le développeur dans son quotidien.

Tout d’abord, il faut savoir que le DbContext n’est pas thread safe. Dans le cadre d’une application web ASP.NET Core, cela veut dire qu’il ne faut pas partager le DbContext entre plusieurs requêtes HTTP, puisqu’une requête équivaut à avoir un nouveau thread. De base, nous allons donc privilégier un service DbContext en mode Scoped au maximum, pas de singleton. Le mode Transient est acceptable. D’ailleurs, lorsque le développeur écrit AddDbContext, c’est exactement ce que le framework fait : il rajoute le DbContext en tant que Scoped (voir chapitre Les nouveaux mécanismes d’ASP NET Core, section L’injection de dépendances pour le détail sur les cycles de vie Scoped et Transient). Avec cette bonne pratique, le développeur s’assure d’avoir un seul DbContext par thread et n’a pas besoin de se préoccuper de la gestion du cycle de vie de cet objet.

Au sein de l’écosystème Entity Framework, on peut souvent entendre parler de pattern Repository et de pattern Unit of Work. Concernant le premier, nous avons déjà démontré dans ce chapitre comment implémenter un dépôt abstrait, souple, réutilisable et hautement testable.

Le concept du pattern Unit of Work est simple : synchroniser et gérer le cycle de vie des objets d’accès à la base de données tout en fournissant...