Modélisation
Installation d’Entity Framework Core
Entity Framework Core a été conçu pour être entièrement déployé à l’aide du gestionnaire de package NuGet développé par Microsoft et intégré à Visual Studio. Comme APT pour le système Debian, NPM pour Node.js ou pip pour Python, NuGet permet de rendre disponibles à tous des librairies en encapsulant les binaires (ou fichiers de code) ainsi que leurs dépendances au sein d’un unique fichier. Ce dernier est tout simplement une archive au format ZIP dont l’extension est .nupkg et qui contient notamment un manifeste définissant les dépendances associées à la librairie et les environnements pour lesquels elle est disponible.
NuGet est principalement utilisé pour la distribution de librairies ciblant la plateforme .NET, mais quelques exceptions existent, notamment dans le cas de bibliothèques JavaScript comme jQuery ou AngularJS.
1. Dans une application .NET
Commençons par la création d’un projet d’application .NET qui utilisera Entity Framework Core. Pour cet exemple, vous utiliserez le modèle Application Console fourni par Visual Studio.
Dans Visual Studio, ouvrez la boîte de dialogue Nouveau projet à partir du menu Fichier - Nouveau - Projet.
Sélectionnez le modèle Application console, renseignez les informations demandées (nom du projet, emplacement…) et validez.

Lors de l’étape de création, il est important de vérifier la version du framework .NET ciblée par l’application. Entity Framework Core n’est en effet compatible qu’avec les versions 4.5.1 et supérieures.
Une fois le projet créé, il faut ajouter le package Microsoft.EntityFrameworkCore à l’aide de NuGet. Deux interfaces pour cet outil sont intégrées à Visual Studio : une interface graphique et une console permettant d’utiliser des lignes de commande.
Interface graphique
Ouvrez l’interface graphique en sélectionnant, via le menu contextuel du projet, l’option Gérer les packages NuGet.

L’onglet Parcourir de cette interface permet de lister et d’effectuer des recherches sur les packages NuGet disponibles....
Deux approches pour deux cas d’utilisation
L’incorporation dans un projet d’une technologie de mappage objet-relationnel comme Entity Framework Core peut être mise en œuvre à tout moment du cycle de développement : en amont, avant que la moindre ligne de code ne soit écrite, ou pendant le développement, suite à la mise en relief d’un défaut de la technologie utilisée ou pour suivre l’évolution de standards de développement. Cette mise en œuvre doit toutefois être effectuée d’une manière adaptée à l’état de la source de données. À cet effet, deux types d’intégrations peuvent être utilisés :
-
Model First, lorsque la source de données n’existe pas quand les développeurs commencent à écrire le code d’accès aux données.
-
Database First, lorsque la source de données existe depuis un certain temps ou qu’elle doit être créée et maintenue par une tierce personne (un DBA - ou DataBase Administrator - par exemple).
1. Model First
L’approche Model First est couramment utilisée lors de l’écriture de petites applications, comme des prototypes ou des applications mobiles. Néanmois, elle n’est pas inadaptée aux applications métier.
Lorsque l’on...
Du modèle de données au modèle objet
Différentes notions relatives au modèle objet utilisé par Entity Framework Core ont été évoquées depuis le début de cet ouvrage. Dans cette section, nous allons mettre en place la structure générale d’un modèle simpliste relatif à la gestion des commandes de clients. Ce modèle sera modifié par la suite de manière à obtenir une couche d’accès répondant à différents besoins.
1. Point d’entrée : DbContext
La classe DbContext est un élément central de l’utilisation d’Entity Framework Core. Elle est présente dans tous les projets utilisant cette technologie par le biais d’une classe dérivée. C’est à partir de cette classe que toutes les manipulations de données peuvent être effectuées et enregistrées au niveau de la source de données.
a. Patron de conception Unit of Work
Unit of Work est le nom d’un patron de conception dont l’objectif est le maintien d’un ensemble d’objets et la répercussion de l’ensemble des modifications qui leur sont apportées. Ces écritures sont généralement effectuées sous la forme d’un ensemble atomique, c’est-à-dire indivisible : lorsqu’une des actions échoue, l’ensemble échoue. Ce principe d’indivision est notamment connu des développeurs à travers l’exemple des transactions utilisées par une écrasante majorité de bases de données relationnelles.
L’article "Comparison of relational database management systems" de Wikipédia donne à ce jour un seul SGBDR n’implémentant pas les transactions : LucidDB. Source : https://en.wikipedia.org/wiki/Comparison_of_relational_database_management_systems.
Ce mode de fonctionnement est implémenté par la classe DbContext au travers d’un objet nommé Change Tracker, qui gère l’état des objets présents dans le contexte de données, ainsi que de la méthode SaveChanges. Comme son nom l’indique, cette dernière répercute vers la source de données toutes les modifications...
Configuration du modèle objet
La configuration du modèle objet est une étape essentielle de la modélisation avec Entity Framework Core. C’est en effet à ce stade que sont définies les véritables caractéristiques de chaque élément du modèle, et par ricochet, de la base de données qui lui est associée.
1. Trois manières de faire
Avec Entity Framework Core, le développeur dispose de trois méthodes différentes pour définir la configuration du modèle.
Ci-après, la définition d’un modèle simple qui expose un type d’entité permettant de stocker des informations basiques relatives à un client : nom, prénom, adresse. Nous allons voir comment la configuration du modèle peut influer sur la base de données qui lui est associée.
public class Context : DbContext
{
protected override void OnConfiguring(DbContextOptionsBuilder
optionsBuilder)
{
base.OnConfiguring(optionsBuilder);
string connectionString = "<ma chaine de connexion>";
optionsBuilder.UseSqlServer(connectionString);
}
public DbSet<Client> Clients { get; set; }
}
public class Client
{
public int ClientId { get; set; }
public string Nom { get; set; }
public string Prenom { get; set; }
public string Adresse1 { get; set; }
public string Adresse2 { get; set; }
public string Adresse3 { get; set; }
public string CodePostal { get; set; }
public string Ville { get; set; }
}
a. Conventions pour simplifier la modélisation
Entity Framework Core intègre nativement de nombreuses conventions destinées à simplifier au maximum la phase de modélisation. Elles couvrent une grande partie du spectre fonctionnel du framework puisqu’elles sont présentes du nommage des tables à la définition des types de colonnes, en passant notamment par les notions...
Scaffolding
Le scaffolding (échafaudage, en français) est une technique dont l’objectif est la génération de code. Plus exactement, il s’agit de générer une structure de base sur laquelle de nouveaux éléments peuvent se greffer, en s’appuyant sur une spécification. Dans le cas d’un projet ASP.NET MVC, cette spécification correspond à quelques paramètres indiquant s’il faut générer une structure vide, un modèle, des éléments d’accès aux données… Pour le cas qui nous intéresse, à savoir l’utilisation d’Entity Framework Core avec une approche Database First, le scaffolding permet la génération d’un modèle objet à partir d’une source de données existante et de nombreux paramètres dont l’objectif est la personnalisation du code généré.
Pour utiliser cette fonctionnalité lors de l’intégration d’Entity Framework Core à une application, il est nécessaire d’installer une librairie complémentaire associée au fournisseur de données choisi. Le nom de cette librairie est construit, par convention, en associant le nom complet du fournisseur de données et le suffixe ".Design". Dans le cas du fournisseur pour SQL Server, dont le nom complet est Microsoft.EntityFrameworkCore.SqlServer, elle a pour nom Microsoft.EntityFrameworkCore.SqlServer.Design.
Une librairie de design contient les instructions utilisées par le fournisseur de données pour générer le code source .NET à partir de la structure de la base de données. Les outils en ligne de commande évoqués à la section Deux approches pour deux cas d’utilisation - Database First tirent tous deux parti des assemblies de design pour effectuer les tâches qui leur sont confiées.
1. Console du gestionnaire de package NuGet
Les commandes PowerShell utilisables avec la console du gestionnaire de package NuGet sont localisées dans un package NuGet nommé Microsoft.EntityFrameworkCore.Tools. Au préalable, il est donc nécessaire de l’installer.
Attention, à l’heure de l’écriture de ces lignes, ce package n’est disponible...
Migrations
Les possibilités d’Entity Framework Core incluent, par l’approche Model First, la gestion de la structure des sources de données. Cette capacité s’exprime au travers du concept de migration.
Le terme migration représente le processus de transformation d’une structure de base de données de manière qu’elle corresponde à un modèle donné. Il prend la forme de code .NET décrivant l’ensemble des opérations nécessaires à la mutation de la source de données. Chaque évolution d’un modèle objet peut ainsi donner lieu à la création automatisée d’une migration.
Comme le scaffolding, les migrations sont gérées au travers des deux outils en ligne de commande que sont la console du gestionnaire de package NuGet et la CLI .NET Core. Ces outils sont complétés par les deux packages NuGet Microsoft.EntityFrameworkCore.Tools et Microsoft.EntityframeworkCore.Tools.DotNet, qui amènent avec eux les outils spécifiques à Entity Framework Core. Les librairies de design associées à chaque fournisseur de données font le pont entre un projet qui contient un modèle objet et les outils en ligne de commande : ils fournissent les éléments permettant l’interprétation et le traitement du modèle objet.
Dans le cas plus particulier des migrations, les outils permettent d’effectuer trois opérations essentielles : la création d’une migration à partir de l’état courant d’un contexte de données, la suppression d’une migration, et enfin l’application d’une migration à la source de données. Un quatrième traitement très intéressant est également implémenté : la génération d’un script différentiel qui décrit les instructions à exécuter pour aller d’un état associé à une migration à celui résultant d’une seconde migration. Nous manipulerons un modèle client/commande simpliste pour mettre en évidence ces différents comportements.
1. Création d’une migration
La création d’une migration suppose l’existence d’un...