Entity Framework : l'approche Code First

Maintenant que nous savons avec quelle entité nous allons travailler, il nous faut encore de quoi la manipuler, une espèce de maître des entités qui les gouvernerait toutes et nous permettrait d'interagir avec elles.

Passons dans la DAL et utilisons l'excellent NuGet pour obtenir la version 4.2  d'EF. (Voir tuto sur NuGet ici : https://rdonfack.developpez.com/tutoriels/dotnet/presentation-gestionnaire-packages-net-nuget/).

NuGet va télécharger et référencer dans la DAL la DLL version 4.2 d'EF.

Créons une classe GarageContext, qui va hériter de DbContext. Le DbContext, dans les autres modèles d'EF, est plutôt connu sous le nom ObjectContext.

Pour faire simple, le DbContext est un ObjectContext simplifié. Il va notamment nous permettre de manipuler nos tables, donc nos DTO, avec des opérations type CRUD (Create Read Update Delete).

namespace CodeFirst.DAL
{
    class GarageContext : DbContext
    {
        public DbSet<EntityHarley> Harleys { get; set; }
    }
}

Avec ceci, nous informons notre contexte de données des entités qui devront être considérées comme des tables et avec lesquelles nous allons donc réaliser nos transactions et nos diverses manipulations, dans le cas présent, une collection d'entités Harley.

On note au passage l'utilisation de DbSet pour marquer l'existence d'une table.

Et maintenant, dernier point, la configuration de la chaîne de connexion à la base de données.

<?xmlversion="1.0"encoding="utf-8"?>
<configuration>
<configSections>
</configSections>
<connectionStrings>
<addname="GarageContext"
                    connectionString="DataSource=.\SQLEXPRESS;IntegratedSecurity=True"
        providerName="System.Data.SqlClient"/>
</connectionStrings>
</configuration>

Détail qui a son importance, le nom de la chaîne de connexion est le même que le nom de notre classe de contexte.

Techniquement, on a (presque ;) fini l'implémentation de Code First dans sa version la plus sommaire. Encore un peu de code dans la DAL et nous allons pouvoir commencer à bidouiller.

Prenons la DAL et ajoutons cette classe.

namespace CodeFirst.DAL
{
    public class HarleyProvider
    {
        public HarleyProvider()
        {
 
        }
 
        public List<EntityHarley> GetAllHarleys()
        {
            using(GarageContext context = new GarageContext())
            {
                return context.Harleys.ToList();
            }
        }
    }
}

Notre solution ressemble maintenant à ça :

Plus qu'à faire un bout de code dans la console :

static void Main(string[] args)
{            
          AfficheAllVehicule();
                    Console.WriteLine("Fin");
                    Console.ReadLine();
}
 
        static void AfficheAllVehicule()
        {
            HarleyProvider harleyProvider = new HarleyProvider();
  
            foreach(EntityHarley harley in harleyProvider.getAll())
            {
                Console.WriteLine(harley);
            }
        }

Avant de procéder à une évolution de la conception objet, nous allons modifier le nom de la base de données.

Pour ce faire, il suffit de modifier le constructeur du GarageContext :

public GarageContext() : base("GarageMendez")
{            
}

On réexécute… Et on observe dans SQL Management Studio.

Voilà notre base renommée (enfin, une autre base est créée avec le bon nom).

Passons maintenant à l'évolution du modèle.

Reprenons donc notre conception objet, à la base très simple, pour la faire évoluer.

Au niveau des DTO, on étoffe pour obtenir ceci :

On obtient donc la solution suivante :

Le Main est quant à lui réduit à ceci :

class Program
    {
        static GarageManager garage = new GarageManager();       
 
        static void Main(string[] args)
        {            
            AfficheAllVehicule();
            Console.WriteLine("Fin");
            Console.ReadLine();
        }
 
        static void AfficheAllVehicule()
        {
      HarleyProvider harleyProvider = new HarleyProvider();
 
            foreach (EntityHarley harley in harleyProvider.getAll())
            {
                Console.WriteLine(harley);
            }
        }
    }

On exécute, et là, on peut observer le message d'erreur suivant :

EF a détecté que notre modèle de données, enfin, nos classes, ont été modifiées depuis la dernière création de la base et nous fait part de ce déphasage.

Avant d'aller plus loin, certains se sont peut-être posé la question. Mais comment EF a-t-il su que les classes ont été modifiées ?

Souvenez-vous de cette table, EdmMetadata, créée automatiquement.

Cette table permet de savoir s’il y a eu un changement dans notre design, on peut d'ailleurs aller la consulter, on y trouve un enregistrement contenant un hachage, « ModelHash », on peut donc en déduire qu'un hash est obtenu à partir des DTO une première fois et que pour les accès suivants, un nouveau hash est calculé, par comparaison EF en déduit si les classes ont été modifiées.

Pour résoudre ce problème, EF nous propose deux solutions, soit manuellement on delete et on met à jour la base, soit on utilise un IDatabaseInitializer…

Étant donné que nous sommes en phase de développement, nous allons prendre la 2e solution, bien plus souple et permettant plus de choses.

Nous allons créer une nouvelle classe, GarageContextInitializer.

class GarageContextInitializer : DropCreateDatabaseIfModelChanges<GarageContext>
    {
        protected override void Seed(GarageContext context)
        {
            List<EntityHarley> listeHarley = new List<EntityHarley>();
            listeHarley.Add(new EntityHarley { Couleur = "Noire", Modele = "Fatbob", Reservoir = 15 });
            listeHarley.Add(new EntityHarley { Couleur = "Blanche", Modele = "Road King", Reservoir = 30 });
            listeHarley.Add(new EntityHarley { Couleur = "Noire", Modele = "883 Iron", Reservoir = 12 });
 
            List<EntityFerrari> listeFerrari = new List<EntityFerrari>();
            listeFerrari.Add(new EntityFerrari { Couleur = "Rouge", Modele = "Enzo" });
            listeFerrari.Add(new EntityFerrari { Couleur = "Bleue", Modele = "California" });
 
            listeHarley.ForEach(entity => context.Harleys.Add(entity));
            listeFerrari.ForEach(entity => context.Ferrari.Add(entity));
        }
    }

On peut voir qu'elle hérite d'une classe, très explicite, DropCreateDatabaseIfModelChanges.

Cette classe est une implémentation de IDatabaseInitializer, qui détruit la base et la recrée si le modèle change, et éventuellement, réinjecte un jeu de données.

C'est le rôle de la méthode « protected override void Seed(GarageContext context) ».

Et maintenant nous allons modifier le constructeur de GarageContext comme suit :

public GarageContext() : base("GarageMendez")

        {
            Database.SetInitializer<GarageContext>(new GarageContextInitializer());
        }

Recompilons et relançons le programme, on obtient :

Tout fonctionne, ma base a été recréée et dans la foulée a été alimentée. Bien sûr, nous n'oublierons pas d'enlever cette feature lors d'une mise en production, ça serait dommage de perdre des données… 

Sachez qu'il existe une dernière solution pour éviter d'avoir un message d'erreur suite à une modification des DTO. C'est Julie Lerman qui en parle sur son blog, il suffit de changer les stratégies d'initialisation, je vous laisse voir ça ici :

./fichiers/turning-off-code-first-database-initialization-completelyhttp://thedatafarm.com/blog/data-access/turning-off-code-first-database-initialization-completely/Maintenant que nous avons implémenté de l'héritage, il serait intéressant de voir comment cela s'est traduit en base.

Voyons ce que nous dit le Management Studio :

On constate que chacune des propriétés propagées par l'héritage a été dupliquée dans les tables Harleys et Ferrari.

Maintenant que nous nous sommes assurés de ce point, établissons la relation entre le garage et les véhicules, en partant du principe qu'un garage peut posséder plusieurs véhicules et qu'un véhicule appartient à un seul garage.

Le moteur de génération de Code First utilise une convention d'écriture. Lors de la génération de la bdd, il va donc examiner vos classes.

La convention utilisée pour symboliser une relation du type « one to many » se fait via les mots clés virtual et ICollection.

Rajoutons les lignes suivantes dans l'entité garage :

public virtual ICollection<EntityVehicule> Vehicules { get; set; }

Et dans l'entité Vehicule nous rajoutons ceci :

public virtual EntityGarage Garage { get; set; }

Réexécutons le programme et observons les changements dans le Management Studio :

Tout d'abord changement de taille, les tables pour les entités Harleys et Ferraris ont disparu pour laisser place à une nouvelle table pour les entités Vehicule. Bien évidemment, c'est l'héritage mis en place qui est responsable de ceci, nous allons voir pourquoi.

En ce qui concerne notre relation entre un garage et ses véhicules, on constate la présence d'un nouveau champ « Garage_ID », FK sur notre garage.

Si tous les types différents de véhicules sont stockés dans la même table, comment faire la différence ? Eh bien, grâce au nouveau champ créé automatiquement, le discriminant (colonne « Discriminator »). Regardons à quoi il ressemble.

Le discriminant porte le nom de la classe, la FK sur le garage est null car nous ne l'avons pas renseigné, les enregistrements sont conformes à ce qui est dans le Seed.

Alors tout d'abord, pourquoi la création d'une seule supertable, correspondant en fait à la classe mère des entités Vehicules ?

Eh bien, par défaut, lorsque rien n'est précisé, Code First décide de créer la base de données selon le mode Table Per Hierarchy et encore par défaut, si rien n'est précisé c'est le nom de la classe qui fait office de discriminant.

Il est possible de customiser le discriminant avec plusieurs colonnes ou bien encore d'utiliser explicitement le mode Table Per Hierarchy.

Ensuite, sachez qu'il est possible de travailler selon un mode Table Per Type et Table Per Classe, mais cela dépasse un peu le cadre du tutoriel, je vous laisse chercher des infos là-dessus si cela vous intéresse.

Nous allons modifier la classe Harley pour y inclure un booléen indiquant l'existence d'une peinture personnalisée, ainsi que la méthode Seed pour prendre en compte la création d'un garage et relier les véhicules à ce garage.

Réexécutons et observons

Nous avons bien récupéré l'id du garage créé, et on observe que le booléen rajouté est bien spécifique aux entités Harleys, il est initialisé à NULL pour les Ferrari n'ayant pas de sens pour ces entités. C'est peut-être dans ce genre de cas qu'un mode Table Per Type serait préférable).

Nous avons réalisé ici une relation très simple , du type « one to many », entre le garage et les véhicules . Mais on aurait pu faire beaucoup plus poussé grâce à l'API Fluent et à la méthode à surcharger « OnModelCreating » qui permet de modifier le schéma afin d'y apporter une plus grande précision sur les besoins requis.

Continuons ce tutoriel dans les techniques avancées en abordant les règles de validation.

Pour l'instant, nous avons été relativement laxistes sur la valeur et le formalisme des données d'entrée. Nous allons mettre un peu plus de rigueur en décorant les propriétés souhaitées avec des attributs adéquats.

On se place dans la classe EntityVehicule, on observe ce que l'on a disposition dans le namespace prévu, à savoir System.ComponentModel.DataAnnotations.

On peut par exemple spécifier qu'une propriété est une clé avec Key, fixer une fourchette avec le Range, indiquer un champ obligatoire avec Required ou bien carrément personnaliser le formalisme avec une expression rationnelle grâce à RegularExpression.

[Range(1,4, ErrorMessage="Le nombre de places est compris entre 1 et 4."]
public int NbPlaces { get; set; }     
[Required(ErrorMessage= "Le champ modèle est obligatoire.")]
public string Modele { get; set; }

Précédemment, je vous ai parlé du DbContext en vous expliquant que c'était une version simplifiée de l'objectContext. C'est effectivement le cas et nombre de méthodes sont masquées pour faciliter l'utilisation du dbContext.

Cependant, pour certains cas, il se peut que vous ayez besoin d'avoir recours à des méthodes exposées uniquement dans l'objectContext. Eh bien, sachez qu'à partir de votre dbContext, il est possible d'obtenir l'accès à un ObjectContext, et pour cause, en interne, c'est un ObjectContext qui fait les traitements.

Pour ce faire, on utilise le fait que DbContext implémente l'interface IObjectContextAdapter, on ajoute alors dans notre GarageContext :

public ObjectContext ObjectContext()
 {
     return (this as IObjectContextAdapter).ObjectContext;
 }

Et voilà, nous avons désormais accès à l'ObjectContext interne de notre DbContext !