Entity Framework Core
Vous avez déjà utilisé un outil de mappage objet-relationnel (ORM) dans plusieurs de vos cours sur .NET ici à OpenClassrooms, probablement sans le savoir. Dans le cours MVC, par exemple, vous avez utilisé Entity Framework (EF) pour construire une base de données à l’aide de migrations code first. EF est l’ORM standard pour .NET, et il est inclus dans la plupart des projets que vous pouvez créer dans Visual Studio.
À travers .NET Core, Microsoft a étendu l’accessibilité d’Entity Framework avec Entity Framework Core (EF Core). Microsoft présente EF Core comme :
une version légère, extensible, open source et multiplateforme de la technologie d’accès aux données Entity Framework.
L’un des mots-clés ici est légère. Par le passé, EF était critiqué par les développeurs en raison de sa taille trop importante. EF Core a par contre changé la donne. Il fonctionne davantage comme un micro-ORM que son prédécesseur.
Soulignons aussi l’importance du caractère multiplateforme d’EF Core. En effet, les développeurs ont longtemps déploré la dépendance des applications .NET au système d’exploitation Windows, mais cette limite a été levée avec .NET Core et EF Core.
Le fait qu’EF Core soit désormais open source est peut-être la plus grande amélioration. C’est aussi ce qui le rend extensible. Si vous avez besoin de fonctionnalités supplémentaires ou que vous voulez modifier ses fonctionnalités pour répondre à vos besoins, vous êtes libre de retoucher son code.
Comme avec d’autres ORM, les développeurs .NET peuvent exploiter EF Core pour interagir avec leurs bases de données en utilisant des objets écrits en C#. Ceux qui doivent souvent écrire tout le code d’accès aux données en partant de zéro lorsqu’ils utilisent d’autres langages ne peuvent que s’en réjouir.
Écrire soi-même les accès aux données peut être très difficile. Les bases de données relationnelles présentent toutes leurs données sous la forme de tableaux, comme une série de feuilles de calcul. Les langages orientés objet comme C# présentent leurs données plutôt comme une série d’objets connectés de manière complexe. Il n’est donc pas facile de concilier les deux.
Ceci explique l’utilité des ORM. Des outils comme EF Core prennent un modèle de données constitué d’objets C# et le convertissent en une forme relationnelle qui correspond au schéma de la base de données relationnelle.
Le procédé est très simple quand on utilise un ORM. Par contre, si vous voulez en créer un par vous-même, ce sera un peu plus compliqué. De plus, ce n’est pas l’objet de mon cours ! Mon but est de vous montrer comment utiliser les outils qui vous seront les plus utiles (comme EF Core).
Autres ORM
Il existe d’autres ORM que vous pouvez utiliser. Ils sont bien trop nombreux pour être tous évoqués ici. Néanmoins, je vais brièvement vous en présenter quelques-uns.
NHibernate
NHibernate est l’un des ORM les plus utilisés pour .NET après Entity Framework. Il simplifie au maximum les tâches courantes de programmation liées à la persistance des données. Si vous utilisez uniquement des procédures stockées pour implémenter la logique métier dans la base de données dans vos applications, ce n’est pas la solution idéale. Cependant, il est particulièrement utile pour les modèles de domaine orientés objet et la logique métier dans le niveau intermédiaire basé sur .NET. NHibernate peut vous aider à supprimer ou à encapsuler le code SQL spécifique à un SGBD, ainsi que la conversion des résultats d’une représentation tabulaire en un graphique d’objets.
Dapper
Ce micro-ORM a récemment gagné en popularité et est même inclus comme option ORM dans Visual Studio lors de la création d’un nouveau projet. L’un de ses avantages est sa fonctionnalité de mappage, qui fonctionne en grande partie comme LINQ dans EF Core, mais fournit également des méthodes d’extension qui simplifient la soumission d’instructions T-SQL à la base de données.
LINQ to DB
Dans les sciences cognitives, les microniveaux sont de très petites unités de pensée ou de communication, et les macroniveaux sont de plus grandes unités. Les mésoniveaux se situent quelque part entre les deux. C’est un peu comme Boucle d’or qui trouve le bol de soupe "juste comme il faut" dans Boucle d’or et les trois ours.
Si Dapper est un micro-ORM et EF un macro-ORM, l’architecture de LINQ to DB est un méso-ORM. Il vous permet de travailler avec des expressions LINQ plutôt qu’avec des requêtes SQL ou T-SQL tout en maintenant une fine couche d’abstraction entre votre code et la base de données. Les requêtes se basent sur des objets et sont donc vérifiées par le compilateur C#. Mais c’est loin d’être aussi lourd que LINQ to SQL ou Entity Framework. Par exemple, il n’y a pas de suivi des modifications. Vous devez donc le gérer vous-même. En revanche, il permet un meilleur contrôle et un accès beaucoup plus rapide à vos données. C’est le plus rapide de tous les ORM basés sur LINQ.
Insight.Database
Il s’agit d’un micro-ORM moins connu, mais vraiment génial. Il a été conçu par le développeur Jon Wagner spécifiquement pour .NET et il est disponible sous forme de package NuGet. Il est extrêmement rapide, léger, simple à implémenter et à utiliser. Il fonctionne avec toutes les bases de données courantes et peut utiliser des procédures stockées ou des requêtes SQL imbriquées.
L’une de ses meilleures caractéristiques est l’implémentation automatique de l’interface. Je n’y reviendrai pas dans ce cours, mais c’est un excellent micro-ORM.
Qu’en est-il du pattern Repository ?
Le pattern Repository est devenu très populaire depuis son introduction dans la communauté informatique en 2004, en tant que partie intégrante de la conception orientée métier.
En résumé, le pattern Repository est l’intermédiaire entre le mappage de données d’un modèle entité et sa logique métier. Créer, mettre à jour, supprimer et sélectionner les entités dans la collection de données se fait en utilisant des méthodes simples que nous avons créées. Il n’est pas nécessaire de se préoccuper de la connectivité des bases de données, des curseurs ou des pointeurs.
Prenons l’exemple suivant, celui d’un pattern Repository générique.
public interface IRepository<T> where T : MonEntiteInitiale
{
IEnumerable<T> Liste();
IEnumerable<T> Liste(Expression<Func<T, bool>> predicat);
T RecupererEntiteParId(int id);
void Ajouter(T entite);
void Supprimer(T entite);
void Modifier(T entite);
}
public abstract class MonEntiteInitiale
{
public int Id { get; protected set; }
}
public class MonRepository<T> : IRepository<T> where T : MonEntiteInitiale
{
private readonly ApplicationDbContext _contexte;
public MonRepository(ApplicationDbContext contexte)
{
_contexte = contexte;
}
public virtual IEnumerable<T> Liste()
{
return _contexte.Set<T>().AsEnumerable();
}
public virtual IEnumerable<T> Liste(
System.Linq.Expressions.Expression<Func<T, bool>> predicat)
{
return _contexte.Set<T>()
.Where(predicat)
.AsEnumerable();
}
public virtual T RecupererEntiteParId(int id)
{
return _contexte.Set<T>().Find(id);
}
public void Ajouter(T entite)
{
_contexte.Set<T>().Add(entite);
_contexte.SaveChanges();
}
public void Modifier(T entite)
{
_contexte.Entry(entite).State = EntityState.Modified;
_contexte.SaveChanges();
}
public void Supprimer(T entite)
{
_contexte.Set<T>().Remove(entite);
_contexte.SaveChanges();
}
}Cet exemple montre un repository générique qui utilise les mêmes méthodes pour effectuer des opérations de base de données, quel que soit le type entité. Il peut être utile pour votre application !
Mais est-ce nécessaire ?
Cela dépend de plusieurs facteurs, comme l’ORM que vous utilisez, les besoins de votre application, les spécifications du client ou simplement vos préférences personnelles.
Si vous utilisez un micro-ORM comme Insight.Database, une partie de votre implémentation consistera à mettre en place un repository tel que celui-ci. Cependant, remarquez que dans l’exemple ci-dessus, nous utilisons toujours Entity Framework pour gérer la connectivité et effectuer les opérations dans la base de données. Le code est simplement un intermédiaire entre les couches logiques.
Est-il donc nécessaire ?
La réponse est oui, non, peut-être.
Il existe beaucoup de débats sur les sujets comme celui-ci dans le monde de la programmation. Vous trouverez des arguments convaincants en faveur de l’utilisation du pattern repository avec Entity Framework Core et d’autres qui vont dans le sens contraire. Il en est ainsi parce que ce modèle est déjà implémenté dans EF Core, alors pourquoi le refaire ?
Dans EF Core, le pattern repository est implémenté au niveau de l’entité. Cela veut dire que chaque entité a ses propres opérations qu’elle peut effectuer dans la base de données. Si je veux insérer une nouvelle instance d’un étudiant dans ma table Etudiants de la base de données, j’appelle tout simplement :
_contexte.Etudiants.Add(etudiant);Moi, je préfère utiliser les outils à ma disposition et ne pas perdre de temps à refaire le travail que quelqu’un d’autre a déjà fait. Cela ne veut pas dire que le repository générique que je vous ai montré précédemment est une mauvaise idée. Au contraire, il pourrait simplifier votre travail (et la maintenance de vos applications) si vous devez l’utiliser, mais vous ne devriez jamais vous sentir obligé d’implémenter un repository supplémentaire par rapport à ce qui est déjà dans EF Core.
Comme pour beaucoup d’autres aspects du développement logiciel, le choix vous appartient.
En résumé
Dans ce chapitre, vous avez appris le concept de mappage objet-relationnel (ORM), c’est-à-dire comment mapper une série d’objets liés, comme des classes C#, au schéma d’une base de données relationnelle. Vous avez également fait la connaissance :
d’Entity Framework (EF) Core, une version légère, open source et multiplateforme de la technologie EF, qui est l’ORM intégré à .NET Core ;
d’autres ORM et micro-ORM alternatifs couramment utilisés avec .NET ;
du pattern repository et de son rôle dans EF.
Il est maintenant temps d’apprendre à utiliser EF pour concevoir et coder un modèle de données pour une application Web .NET. Ensuite, il sera question d’utiliser les migrations code first pour générer une base de données relationnelle fonctionnelle à partir de ce modèle.
