A la découverte d’Entity Framework Core – Deuxième partie

Cet article s’adresse aux personnes connaissant déjà Entity Framework (EF) et a pour objectif d’être un répertoire de patrons de développement utiles dans vos projets.

Dans la première partie de cette série d’articles, nous avons vu le fonctionnement de base mais également quelques modèles basiques. Ici, il sera question de voir ce qu’Entity Framework peut nous apporter en matière de tests et de maintenance.

Migrations

Présentation du modèle

Revenons un peu sur le modèle que nous avions au début de l’article :

Nous souhaitons le faire évoluer et passer à ce modèle :

Pour ce faire, nous devrions créer les scripts SQL de migrations et modifier notre code.

Migration avec Entity Framework

Entity Framework propose une migration automatique qui dépend du code que vous avez écrit.

Avant de commencer la modification de notre modèle, nous devons établir son état initial. Après avoir ajouté le package nuGet Microsoft.EntityFrameworkCore.Design, passons dans la console :

> cd myProject

> dotnet ef migrations add InitialModel

Entity framework va générer du code, présent dans votre projet :

Examinons à présent ces fichiers :

Dans ce premier fichier, on voit une classe qui décrit les tables et relations qui constituent notre modèle. La méthode Down permet également de revenir à l’état initial. En l’occurrence, cette partie est inutile puisque c’est notre première migration, mais dès notre deuxième migration, nous pourrions rollbacker nos changements très facilement.

• Le fichier 20190327140203_Initial.Designer.cs contient des méta-datas qui décrivent notre modèle. Il est très rare d’avoir à modifier quoi que ce soit ici.
• Le fichier BlogContextModelSnapshot.cs contient l’état actuel de la base après l’exécution de la dernière migration.

Si nous repassons en ligne de commande, nous allons appliquer la migration à une base existante :

> dotnet ef database update

Cette ligne va appliquer la migration sur la base de données configurée dans le DbContexte dans la méthode OnConfiguring. En vous connectant sur la base, vous pourrez voir que le modèle a été créé.

Ajoutons maintenant la jointure vers l’entité Category à notre contexte

> dotnet ef migrations add AddCategory

Voici le fichier de migration :

La migration est assez facile à lire, dans notre cas, Entity Framework nous a même créé une valeur par défaut pour les colonnes non nullable. Il est recommandé de vérifier ce que contient la migration, surtout pour les jointures un peu plus complexes.

La contrepartie de la classe pour les méta-datas est toujours présente et le fichier snapshot a été mis à jour.

En cas d’erreur dans la migration, il est quelquefois plus avantageux de carrément l’effacer, de corriger son modèle et de régénérer une migration. Pour cela, utiliser la commande prévue pour :

> dotnet ef migrations remove

La dernière migration sera effacée et le fichier snapshot restauré à sa valeur antérieure.

Le Scaffolding dans Entity Framework

Dans la vraie vie de la réalité véritable, il est assez rare de partir d’une base de données vide, comment alors appliquer Code First ? Là encore, Entity Framework est livré avec des outils pour nous aider, il s’agit du scafolding !

> dotnet ef dbcontext scaffold <connexion_string>

Cette commande va créer la classe DbContext correspondant à votre modèle ainsi que toutes les entités correspondant à chacune de vos tables. Il est fortement recommandé de jeter un coup d’œil au code généré, des propriétés de navigation peuvent avoir été créé alors qu’elles sont inutiles. Si c’est le cas, effacez-les de votre contexte/entité et créez une nouvelle migration (afin qu’une « vraie » migration ultérieure ne comporte que les éléments ayant été réellement modifiés).

Tests

Lorsqu’on développe des services attaquant une base de données, nous avons 2 solutions pour tester le fonctionnement :

• Créer une base de test sur lequel nous connecterons le code lors de l’exécution des tests. Notre code sera testé « pour de vrai », avec les performances et comportements d’une vraie base de données.
  L’inconvénient, c’est qu’il est quelques-fois difficile de se connecter à une base de données depuis notre usine de build et surtout, que nos tests deviennent très dépendants de l’état de la base de données. Il faut également penser à faire le ménage en fin de test pour laisser la base dans l’état où on l’a trouvée.
• Deuxième solution, monter en mémoire une base de données de test dans laquelle on aura remplis que quelques lignes, uniquement pour tester la fonctionnalité attendue. C’est cette approche que nous allons détailler ici.

Pour activer le montage de la base de données en mémoire, il suffit de changer les options qu’on passe au constructeur du dbContext :

L’objet dbContext est tout à fait fonctionnel avec quelques limitations : les propriétés de navigation sont remplies par défaut, ce qui n’est pas le cas pour un contexte attaché à une vraie base de données. Mais cela permet de tester un minimum ses services.

Conclusion

Cette série d’articles nous a permis de voir un certain nombre de modèles utiles pour le développement. Dans cette seconde partie, nous avons vu commet tester nos services utilisant notre modèle mais également comment maintenir ce modèle grâce aux migrations.

Bien entendu, le sujet est vaste et ne peut remplacer la documentation officielle : https://docs.microsoft.com/fr-fr/ef/core/