Presentation d’Entity Framework

Voici un premier billet présentant de manière générale l’outil de mapping objet relationnel proposé par Microsoft : Entity Framework. Je proposerai par la suite d’autres billets sur des points spécifiques au mapping objet relationnel tels que :

  • les identifiants
  • les associations entre entités
  • l’héritage
  • les stratégies de chargement

Afin de lever toute ambiguïté, je tiens à préciser que j’arrive du monde Hibernate, un outil de mapping objet relationnel open source reconnu et aujourd’hui normalisé avec JPA (Java Persistence API). C’est pourquoi je ferai régulièrement référence à cet outil que j’apprécie particulièrement. Ceux qui connaissent (N)Hibernate ne seront pas trop dépaysés car certains mécanismes ont été repris.

La première version d’Entity Framework ne m’a pas vraiment convaincu.

  • L’idée fondamentale qui est de séparer le modèle conceptuel (CSDL : Conceptual Schema Definition Language), du modèle logique de bases de données (SSDL : Store Schema Definition Language) en détaillant le mapping dans un schéma de liaison (MSL : Mapping Specification Language) est théoriquement très intéressant mais se révèle assez lourd dans la pratique : le designer proposé dans Visual Studio étant limité, il faut très rapidement éditer LE fichier XML manuellement qui est encore plus verbeux qu’un fichier de mapping Hibernate !
  • Par ailleurs, les objets entités étaient nécessairement très liés au framework : héritage d’implémentation, utilisation de collections propres à EF…
  • L’approche outillée était une approche relationnelle : à partir d’un modèle relationnel et EF génère des classes persistantes.

Avec la nouvelle version (Entity Framework 4), et notamment avec Entity Framework Feature CTP 3, également connu sous le nom de code-first, je commence à trouver l’outil très intéressant.

Comme son nom l’indique, code-first permet d’écrire des classes en premier, puis de générer un modèle relationnel issu de ces classes. C’est cette approche que je vous propose d’aborder dans ces billets avec la modélisation d’un système d’information (très simplifié) d’une banque. Dans une banque le client est roi, nous commencerons donc par la classe Client:

public class Client{
   public int Id { get; set;}
   public string Nom { get; set;}
   public string Prenom { get; set;}
}

Pour fournir à Entity Framework les informations de mapping, nous utiliserons le mode fluent. Pour cela, on définit généralement une classe de configuration par entité qui étend de EntityConfiguration<T>.

public class ClientConfiguration : EntityConfiguration<Client>{
   public ClientConfiguration(){

   // la propriété Id est l'identifiant de base de données
   this.Property( client => client.Id)
        .IsIdentity();

   // la propriété Nom ne peut pas être null
   // elle a une taille max de 200
   this.Property( client => client.Nom)
        .IsRequired()
        .HasMaxLength(200);
   }
}

Cette manière d’utiliser les lambdas expressions est de plus en plus fréquente en C#. On la retrouve notamment dans Fluent Nhibernate. Les fichiers de mapping XML sont contraignants à éditer et à maintenir. Les annotations sont plus simples d’utilisation mais leur présence dans nos classes POCO impliquent une forme d’adhérence vers le framework : une dépendance de compilation. Dans une application RIA avec Silverlight , il est fréquent de référencer l’assembly contenant le modèle du domaine. Mais une dépendance de compilation des classes du domaine vers un framework de mapping objet relationnel rend caduque ce référencement. Le mode fluent permet de décrire le mapping dans une assembly tierce, sans la lourdeur du XML avec en prime une vérification au moment de la compilation, de la complétion et du refactoring !

Je détaillerai dans mon prochain billet la configuration du ContextBuilder à partir de nos classes de configuration. C’est l’équivalent de la SessionFactory. Une fois configurée, cette fabrique va permettre  à EF de générer notre schéma de bases de données. Par défaut, il va créer une table Clients avec 3 colonnes :

  1. Id : la clé primaire de la table auto incrémentée
  2. Nom : un nvarchar de 200 non null
  3. Prenom

Nous avons vu dans ce premier billet la mise en place d’un mapping simple entre un POCO vers une base de données relationnelle, les éléments de mapping étant fournis dans une classe C# en mode fluent.

3 réflexions au sujet de « Presentation d’Entity Framework »

Laisser un commentaire

Votre adresse de messagerie ne sera pas publiée. Les champs obligatoires sont indiqués avec *