Introduction par l'exemple à Entity Framework 5 Code First

Elle contient des informations sur les médecins gérés par l'application [RdvMedecins].

• ID : n° identifiant le médecin - clé primaire de la table
• VERSION : n° identifiant la version de la ligne dans la table. Ce nombre est incrémenté de 1 à chaque fois qu'une modification est apportée à la ligne.
• NOM : le nom du médecin
• PRENOM : son prénom
• TITRE : son titre (Mlle, Mme, Mr)

Nous pourrions partir de la classe [Medecin] suivante :

using System;

[Table("MEDECINS", Schema = "dbo")]
  namespace RdvMedecins.Entites
{
  public class Medecin
  {
    // data
    public int Id { get; set; }
    public string Titre { get; set; }
    public string Nom { get; set; }
    public string Prenom { get; set; }
}

• ligne 3 : la classe [Medecin] est associée à la table [MEDECINS] de la base de données. Celle-ci se trouvera dans un schéma nommé " dbo ".

Nous mettons cette classe dans un fichier [Entites.cs] [1]. C'est là que nous placerons toutes nos entités.

Toujours dans le dossier [Models], nous créons le fichier [Context.cs] suivant :

using System.Data.Entity;
using RdvMedecins.Entites;

namespace RdvMedecins.Models
{

  // le contexte
  public class RdvMedecinsContext : DbContext
  {
    // les médecins
    public DbSet<Medecin> Medecins { get; set; }
  }

  // initialisation de la base
  public class RdvMedecinsInitializer : DropCreateDatabaseAlways<RdvMedecinsContext>
  {
  }
}

• ligne 8 : la classe [RdvMedecinsContext] va représenter le contexte de persistance, c.-à-d. l'ensemble des entités gérées par l'ORM. Elle doit dériver de la classe [System.Data.Entity.DbContext] ;
• ligne 11 : le champ [Medecins] va représenter les entités de type [Medecin] du contexte de persistance. Il est de type DbSet<Medecin>. On trouvera généralement autant de [DbSet] que de tables dans la base, un par table ;
• ligne 15 : on définit une classe [RdvMedecinsInitializer] pour initialiser la base créée. Ici elle dérive de la classe [DropCreateDataBaseAlways] qui comme son nom l'indique supprime la base si elle existe déjà puis la recrée. C'est pratique en phase de développement de la BD. Le paramètre de la classe [DropCreateDataBaseAlways] est le type de contexte de persistance associé à la base. On peut utiliser d'autres classes mères que [DropCreateDataBaseAlways] pour la classe d'initialisation :
• [DropCreateDatabaseIfModelChanges] : recrée la base si les entités ont changé,
• [CreateDatabaseIfNotExists] : crée la base si elle n'existe pas ;

Il nous reste à créer un programme principal. Ce sera le suivant [CreateDB_01.cs] :

using System;
using System.Data.Entity;
using RdvMedecins.Models;

namespace RdvMedecins_01
{
  class CreateDB_01
  {
    static void Main(string[] args)
    {
      // on crée la base
      Database.SetInitializer(new RdvMedecinsInitializer());
      using (var context = new RdvMedecinsContext())
      {
        context.Database.Initialize(false);
      }
    }
  }
}

• ligne 12 : [System.Data.Entity.DataBase] est une classe offrant des méthodes statiques pour gérer la base associée à un contexte de persistance. La méthode statique [SetInitializer] permet de préciser la classe d'initialisation de la base. Cela ne lance pas l'initialisation ;
• ligne 13 : pour travailler avec un contexte de persistance, il faut instancier celui-ci. C'est ce qui est fait ici. On utilise une clause using afin que le contexte soit automatiquement fermé à la sortie de la clause. Donc ligne 17, le contexte est fermé ;
• ligne 15 : on lance explicitement la génération de la base associée au contexte de persistance [RdvMedecinsContext]. Le paramètre false indique que cette opération ne doit pas être faite si elle a déjà été faite pour ce contexte. Ici, on aurait tout aussi bien pu mettre true.

Lorsqu'on travaille avec une base de données, les paramètres de connexion sont généralement inscrits dans le fichier [App.config]. Constatons que pour l'instant, ils n'y sont pas :

<?xml version="1.0" encoding="utf-8"?>
<configuration>
  <configSections>
    <!-- For more information on Entity Framework configuration, visit http://go.microsoft.com/fwlink/?LinkID=237468 -->
    <section name="entityFramework" type="System.Data.Entity.Internal.ConfigFile.EntityFrameworkSection, EntityFramework, Version=5.0.0.0, Culture=neutral, PublicKeyToken=b77a5c561934e089" requirePermission="false" />
  </configSections>
  <startup>
    <supportedRuntime version="v4.0" sku=".NETFramework,Version=v4.5" />
  </startup>
  <entityFramework>
    <defaultConnectionFactory type="System.Data.Entity.Infrastructure.SqlConnectionFactory, EntityFramework" />
  </entityFramework>
</configuration>

Les éléments ci-dessus ont été inscrits dans [App.config] lorsqu'on a ajouté la dépendance Entity Framework aux références du projet.

Exécutons le projet (Ctrl-F5) après avoir lancé SQL Server Express (c'est important) :

L'exécution doit se terminer sans erreur. Ouvrons maintenant l'outil d'administration de SQL Server et rafraîchissons l'affichage :

On constate qu'une base portant le nom complet de la classe [RdvMedecinsContext] a été créée et qu'elle contient une table [dbo.MEDECINS] (c'est le nom qu'on lui avait donné) avec des colonnes qui reprennent les noms des champs de l'entité [Medecin]. Si le code s'est bien exécuté et que la base ci-dessus n'apparaît pas, il faut regarder le serveur embarqué (localdb)\v11.0 (cf. page ). Avec VS 2012 pro, ce serveur est utilisé si SQL Server n'est pas actif au moment de l'exécution du code. Avec VS 2012 Express, non.

Examinons la structure de la table [MEDECINS] :

• elle reprend les noms des champs de l'entité [Medecin] ;
• la colonne [Id] est clé primaire. C'est une convention d'EF : si l'entité E a un champ Id ou Eid (MedecinId), alors cette colonne est clé primaire dans la table associée ;
• les types des colonnes de la table sont ceux des champs de l'entité ;
• pour les colonnes Titre, Nom, Prenom, un type [nvarchar(max)] a été utilisé. On pourrait être plus précis, 5 caractères pour le titre, 30 pour les nom et prénom ;
• les colonnes Titre, Nom, Prenom peuvent avoir la valeur NULL. Nous allons changer cela.

Regardons les propriétés de la clé primaire [Id] :

En [1], on voit que la clé primaire est de type [Identité], ce qui signifie que sa valeur est automatiquement générée par SQL Server. Nous adopterons cette stratégie avec tous les SGBD.

Nous allons laisser moins de part aux conventions d'EF en utilisant des annotations. Le code de l'entité dans [Entites.cs] devient le suivant :

using System;
using System.ComponentModel.DataAnnotations;
using System.ComponentModel.DataAnnotations.Schema;

namespace RdvMedecins.Entites
{
  [Table("MEDECINS", Schema = "dbo")]
  public class Medecin
  {
    // data
    [Key]
    [Column("ID")]
    public virtual int Id { get; set; }
    [Required]
    [MaxLength(5)]
    [Column("TITRE")]
    public virtual string Titre { get; set; }
    [Required]
    [MaxLength(30)]
    [Column("NOM")]
    public virtual string Nom { get; set; }
    [Required]
    [MaxLength(30)]
    [Column("PRENOM")]
    public virtual string Prenom { get; set; }
    [Required]
    [Column("VERSION")]
    public virtual int Version { get; set; }
  }
}

• lignes 2 et 3 : les annotations sont trouvées dans les espaces de noms [System.ComponentModel.DataAnnotations] (Key, Required, MaxLength] et [System.ComponentModel.DataAnnotations.Schema] (Column). On trouvera d'autres annotations à l'URL [http://msdn.microsoft.com/en-us/data/gg193958.aspx];
• ligne 11 : [Key] désigne la clé primaire ;
• ligne 12 : [Column] fixe le nom de la colonne correspondant au champ ;
• ligne 14 : [Required] indique que le champ est obligatoire (SQL NOT NULL) ;
• ligne 15 : [MaxLength] fixe la taille maxi de la chaîne de caractères, [MinLength] sa taille mini ;

Exécutons le projet avec cette nouvelle définition de l'entité [Medecin]. La base créée est alors la suivante :

• les colonnes ont le nom qu'on leur a fixé ;
• l'annotation [Required] a été traduite par un SQL NOT NULL ;
• l'annotation [MaxLength(N)] a été traduite par un type SQL nvarchar(N).

Dans l'application NHibernate, la colonne [VERSION] était là pour prévenir les accès concurrents à une même ligne d'une table. Le principe est le suivant :

• un processus P1 lit une ligne L de la table [MEDECINS] au temps T1. La ligne a la version V1 ;
• un processus P2 lit la même ligne L de la table [MEDECINS] au temps T2. La ligne a la version V1 parce que le processus P1 n'a pas encore validé sa modification ;
• le processus P1 valide sa modification de la ligne L. La version de la ligne L passe alors à V2=V1+1 ;
• le processus P2 valide sa modification de la ligne L. L'ORM lance alors une exception car le processus P2 a une version V1 de la ligne L différente de la version V2 trouvée en base.

On appelle cela la gestion optimiste des accès concurrents. Avec EF 5, un champ jouant ce rôle doit avoir l'un des deux attributs [Timestamp] ou [ConcurrencyCheck]. SQL Server a un type [timestamp]. Une colonne ayant ce type voit sa valeur automatiquement générée par SQL Server à toute insertion / modification d'une ligne. Une telle colonne peut alors servir à gérer la concurrence d'accès. Pour reprendre l'exemple précédent, le processus P2 trouvera un timestamp différent de celui qu'il a lu, car entre-temps la modification faite par le processus P1 l'aura modifié.

Notre entité [Medecin] évolue comme suit :

using System;
using System.ComponentModel.DataAnnotations;
using System.ComponentModel.DataAnnotations.Schema;

namespace RdvMedecins.Entites
{
[Table("MEDECINS", Schema = "dbo")]
public class Medecin
  {
    // data
    [Key]
    [Column("ID")]
    public int Id { get; set; }
    [Required]
    [MaxLength(5)]
    [Column("TITRE")]
    public string Titre { get; set; }
    [Required]
    [MaxLength(30)]
    [Column("NOM")]
    public string Nom { get; set; }
    [Required]
    [MaxLength(30)]
    [Column("PRENOM")]
    public string Prenom { get; set; }
    [Column("TIMESTAMP")]
    [Timestamp]
    public byte[] Timestamp { get; set; }
  }
}

• lignes 26-28 : la nouvelle colonne avec l'attribut [Timestamp] de la ligne 27. Le type du champ doit être byte[] (ligne 28). Le nom du champ peut être quelconque. On ne lui met pas l'attribut [Required] car ce n'est pas l'application qui fournira cette valeur mais le SGBD lui-même.

Si on exécute le projet avec cette nouvelle entité, la base évolue comme suit :

Il nous reste à régler un dernier point. Le contexte de persistance " sait " qu'une entité doit faire l'objet d'une insertion en base parce qu'alors elle a sa clé primaire égale à null. C'est l'insertion en base qui va donner une valeur à la clé primaire. Ici, le type int donné à la clé primaire [Id] ne convient pas parce que ce type n'accepte pas la valeur null. On lui donne alors le type int? qui accepte les valeurs int plus le pointeur null. L'entité [Medecin] utilisée sera donc la suivante :

public class Medecin
  {
    // data
    [Key]
    [Column("ID")]
    public virtual int? Id { get; set; }
    ...

Il nous reste à voir comment représenter dans une entité le concept de clé étrangère entre tables.

La table [CRENEAUX] liste les créneaux horaires où les RV sont possibles :

• ID : n° identifiant le créneau horaire - clé primaire de la table
• VERSION : n° identifiant la version de la ligne dans la table. Ce nombre est incrémenté de 1 à chaque fois qu'une modification est apportée à la ligne.
• ID_MEDECIN : n° identifiant le médecin auquel appartient ce créneau - clé étrangère sur la colonne MEDECINS(ID).
• HDEBUT : heure début créneau
• MDEBUT : minutes début créneau
• HFIN : heure fin créneau
• MFIN : minutes fin créneau

La seconde ligne de la table [CRENEAUX] (cf [1] ci-dessus) indique, par exemple, que le créneau n° 2 commence à 8 h 20 et se termine à 8 h 40 et appartient au médecin n° 1 (Mme Marie PELISSIER).

Avec ce que nous savons, nous pouvons définir l'entité [Creneau] comme suit dans [Entites.cs] :

[Table("CRENEAUX", Schema = "dbo")]
  public class Creneau
  {
    // data
    [Key]
    [Column("ID")]
    public int? Id { get; set; }
    [Required]
    [Column("HDEBUT")]
    public int Hdebut { get; set; }
    [Required]
    [Column("MDEBUT")]
    public int Mdebut { get; set; }
    [Required]
    [Column("HFIN")]
    public int Hfin { get; set; }
    [Required]
    [Column("MFIN")]
    public int Mfin { get; set; }
    [Required]
    public virtual Medecin Medecin { get; set; }
    [Column("TIMESTAMP")]
    [Timestamp]
    public byte[] Timestamp { get; set; }
}

La seule nouveauté réside aux lignes 20-21. Le fait que la table [CRENEAUX] ait une clé étrangère sur la table [MEDECINS] est reflété dans l'entité [Creneau] par la présence d'une référence sur l'entité [Medecin], ligne 21. Le nom du champ importe peu, seul le type est important. La propriété doit être déclarée virtuelle avec le mot clé virtual . En effet, EF est amené à redéfinir toutes les propriétés dites navigationnelles , c'-a-d celles qui correspondent à une clé étrangère et qui permettent de passer d'une table à l'autre.

Pour tester la nouvelle entité, il nous faut faire quelques modifications dans [Context.cs] :

using System.Data.Entity;
using RdvMedecins.Entites;

namespace RdvMedecins.Models
{

  // le contexte
  public class RdvMedecinsContext : DbContext
  {
    // les entités
    public DbSet<Medecin> Medecins { get; set; }
    public DbSet<Creneau> Creneaux { get; set; }
  }

  // initialisation de la base
  public class RdvMedecinsInitializer :  DropCreateDatabaseIfModelChanges<RdvMedecinsContext>
  {
  }
}

La ligne 12 reflète le fait que le contexte a une entité de plus à gérer. Lorsque nous exécutons le projet, nous obtenons la nouvelle base suivante :

La table [CRENEAUX] a bien été créée et la nouveauté est la présence d'une clé étrangère [1] et [2]. Son nom a été généré à partir du nom du champ correspondant dans l'entité (Medecin) suffixé par " _Id ". Pour connaître les propriétés de cette clé étrangère, on essaie de la modifier [3].

La copie d'écran ci-dessus montre que [Medecin_Id] est clé étrangère de la table [CRENEAUX] et qu'elle référence la clé primaire [ID] de la table [MEDECINS].

Si on crée les entités pour une base existante, la colonne clé étrangère ne s'appellera pas forcément [Medecin_Id]. Pour les autres colonnes, on avait vu que l'annotation [Column] réglait ce problème. Bizarrement c'est plus compliqué pour une clé étrangère. Il faut procéder de la façon suivante :

public class Creneau
  {
    // data
    ...
    [Required]
    [Column("MEDECIN_ID")]
    public int MedecinId { get; set; }
    [Required]
    [ForeignKey("MedecinId")]
    public virtual Medecin Medecin { get; set; }
    ...
}

• lignes 5-7 : on crée un champ du type de la clé étrangère (int). A l'aide de l'attribut [Column], on précise le nom de la colonne qui sera clé étrangère dans la table associée à l'entité ;
• ligne 9 : on ajoute l'annotation [ ForeignKey ] au champ de type [Medecin]. L'argument de cette annotation est le nom du champ (pas de la colonne) qui est associé à la colonne clé étrangère de la table.

L'exécution du projet crée cette fois-ci la table suivante :

Ci-dessus, la colonne clé étrangère porte bien le nom qu'on lui a donné. Il faut noter que les champs :

    [Required]
    [Column("MEDECIN_ID")]
    public int MedecinId { get; set; }
    [Required]
    [ForeignKey("MedecinId")]
public virtual Medecin Medecin { get; set; }

n'ont donné naissance qu'à une seule colonne, la colonne [MEDECIN_ID]. Néanmoins, la présence du champ [MedecinId] est importante. Lors de la lecture d'une ligne de la table [CRENEAUX], elle recevra la valeur de la colonne [MEDECIN_ID], c'-à-d. la valeur de la clé étrangère sur la table [MEDECINS]. Cela est souvent utile.

Le champ [Medecin] ci-dessus reflète la relation plusieurs à un qui lie l'entité [Creneau] à l'entité [Medecin]. Plusieurs objets [Creneau] sont reliés à un même [Medecin]. La relation inverse, un objet [Medecin] est associé à plusieurs objets [Creneau] peut être modélisée par un champ supplémentaire dans l'entité [Medecin] :

public class Medecin
  {
    // data
    [Key]
    [Column("ID")]
    public int? Id { get; set; }
    ...
    public ICollection<Creneau> Creneaux { get; set; }
    [Column("TIMESTAMP")]
    [Timestamp]
    public byte[] Timestamp { get; set; }

Ligne 8, on a rajouté le champ [Creneaux] qui est une collection d'objets [Creneau]. Ce champ nous donnera accès à tous les créneaux horaires du médecin.

Lorsqu'on exécute de nouveau le projet, on constate que la table [MEDECINS] n'a pas bougé :

Aucune colonne n'a été rajoutée. La relation de clé étrangère qui existe entre la table [CRENEAUX] et la table [MEDECINS] est suffisante pour que EF sache générer les champs liés à celle-ci :

public class Medecin
  {
    ...
    public ICollection<Creneau> Creneaux { get; set; }
    ...
  }

  public class Creneau
  {
    ...
    [Required]
    [Column("MEDECIN_ID")]
    public int MedecinId { get; set; }
    [Required]
    [ForeignKey("MedecinId")]
    public virtual Medecin Medecin { get; set; }
    ...
  }

Nous savons l'essentiel. Nous pouvons terminer avec la création des deux autres entités.

Avec ce que nous avons appris, nous pouvons écrire les entités [Client] et [Rv]. L'entité [Client] contient des informations sur les clients gérés par l'application [RdvMedecins].

• ID : n° identifiant le client - clé primaire de la table
• VERSION : n° identifiant la version de la ligne dans la table. Ce nombre est incrémenté de 1 à chaque fois qu'une modification est apportée à la ligne.
• NOM : le nom du client
• PRENOM : son prénom
• TITRE : son titre (Mlle, Mme, Mr)

L'entité [Client] pourrait être la suivante :

  [Table("CLIENTS", Schema = "dbo")]
  public class Client
  {
    // data
    [Key]
    [Column("ID")]
    public int? Id { get; set; }
    [Required]
    [MaxLength(5)]
    [Column("TITRE")]
    public string Titre { get; set; }
    [Required]
    [MaxLength(30)]
    [Column("NOM")]
    public string Nom { get; set; }
    [Required]
    [MaxLength(30)]
    [Column("PRENOM")]
    public string Prenom { get; set; }
    // les Rvs du client
    public ICollection<Rv> Rvs { get; set; }
    [Column("TIMESTAMP")]
    [Timestamp]
    public byte[] Timestamp { get; set; }
}

La classe [Client] est quasi identique à la classe [Medecin]. On pourrait les faire dériver d'une même classe parent. La nouveauté est ligne 21. Elle reflète le fait qu'un client peut avoir plusieurs rendez-vous et dérive de la présence d'une clé étrangère de la table [RVS] vers la table [CLIENTS].

L'entité [Rv] représente un rendez-vous :

• ID : n° identifiant le RV de façon unique - clé primaire
• JOUR : jour du RV
• ID_CRENEAU : créneau horaire du RV - clé étrangère sur la colonne [ID] de la table [CRENEAUX] - fixe à la fois le créneau horaire et le médecin concerné.
• ID_CLIENT : n° du client pour qui est faite la réservation - clé étrangère sur la colonne [ID] de la table [CLIENTS]

L'entité [Rv] pourrait être la suivante :

[Table("MEDECINS", Schema = "dbo")]
  public class Rv
  {
    // data
    [Key]
    [Column("ID")]
    public int? Id { get; set; }
    [Required]
    [Column("JOUR")]
    public DateTime Jour { get; set; }
    [Column("CLIENT_ID")]
    public int ClientId { get; set; }
    [ForeignKey("ClientId")]
    [Required]
    public virtual Client Client { get; set; }
    [Column("CRENEAU_ID")]
    public int CreneauId { get; set; }
    [ForeignKey("CreneauId")]
    [Required]
    public virtual Creneau Creneau { get; set; }
    [Column("TIMESTAMP")]
    [Timestamp]
    public byte[] Timestamp { get; set; }
}

• lignes 5-7 : clé primaire ;
• lignes 8-10 : date du rendez-vous ;
• lignes 11-12 : la clé étrangère de la table [RVS] vers la table [CLIENTS] ;
• lignes 13-15 : le client qui a rendez-vous ;
• lignes 16-17 : la clé étrangère de la table [RVS] vers la table [CRENEAUX] ;
• lignes 18-20 : le créneau horaire du rendez-vous ;
• lignes 21-23 : le champ de gestion des accès concurrents.

Ligne 17, on voit une relation plusieurs à un : à un créneau horaire peuvent correspondre plusieurs rendez-vous (pas le même jour). La relation inverse peut être reflétée dans l'entité [Creneau] :

• public class Creneau
• {
• // les Rvs du créneau
• public ICollection < Rv > Rvs { get ; set ; }
• …
• }

Ligne 4, la collection des rendez-vous pris sur ce créneau horaire.

Lorsqu'on exécute le projet, la base générée est la suivante :

Les tables [MEDECINS] et [CRENEAUX] n'ont pas changé. Les tables [CLIENTS] et [RVS] sont les suivantes :

C'est ce qui était attendu. Il nous reste quelques détails à régler :

• gérer le nom de la base. Ici il a été généré par EF ;
• remplir la base avec des données.

Pour fixer le nom de la base générée par EF, nous utiliserons une chaîne de connexion définie dans [App.config]. Ce fichier de configuration évolue comme suit :

<?xml version="1.0" encoding="utf-8"?>
<configuration>
  <configSections>
    <!-- For more information on Entity Framework configuration, visit http://go.microsoft.com/fwlink/?LinkID=237468 -->
    <section name="entityFramework" type="System.Data.Entity.Internal.ConfigFile.EntityFrameworkSection, EntityFramework, Version=5.0.0.0, Culture=neutral, PublicKeyToken=b77a5c561934e089" requirePermission="false" />
  </configSections>
  <startup>
    <supportedRuntime version="v4.0" sku=".NETFramework,Version=v4.5" />
  </startup>
  <entityFramework>
    <defaultConnectionFactory type="System.Data.Entity.Infrastructure.SqlConnectionFactory, EntityFramework" />
  </entityFramework>

  <!-- chaîne de connexion sur la base -->
  <connectionStrings>
    <add name="RdvMedecinsContext"
         connectionString="Data Source=localhost;Initial Catalog=rdvmedecins-ef;User Id=sa;Password=sqlserver2012;"
         providerName="System.Data.SqlClient" />
  </connectionStrings>
  <!-- le factory provider -->
  <system.data>
    <DbProviderFactories>
      <add name="SqlClient Data Provider"
       invariant="System.Data.SqlClient"
       description=".Net Framework Data Provider for SqlServer"
       type="System.Data.SqlClient.SqlClientFactory, System.Data,
     Version=4.0.0.0, Culture=neutral, PublicKeyToken=b77a5c561934e089"
    />
    </DbProviderFactories>
  </system.data>

</configuration>

• lignes 15-19 : la chaîne de connexion à la base ;
• ligne 16 : l'attribut [name] reprend le nom de la classe [RdvMedecinsContext] utilisé pour le contexte de persistance. Il est important de s'en souvenir. Cette contrainte peut être contournée dans le constructeur du contexte :

// constructeur
    public RdvMedecinsContext()
      : base("monContexte")
    {
    }

Dans ce cas, on pourra avoir name= "monContexte " . C'est ce que nous aurons dans la suite du document.

• ligne 17 : la chaîne de connexion. [Data Source] : le nom du serveur sur lequel se trouve le SGBD, [Initial Catalog] : le nom de la base de données, donc ici [rdvmedecins-ef], [User Id] : le propriétaire de la connexion, [Password] : son mot de passe. Le lecteur adaptera cette chaîne à son environnement ;
• lignes 21-29 : définissent un [DbProviderFactory]. Je ne sais pas ce que c'est. Si j'en crois le nom, ce pourrait être une classe permettant de générer la couche [ADO.NET] qui sépare EF du SGBD :

En fait, ces lignes sont inutiles pour SQL Server mais j'ai du les ajouter pour les autres SGBD. Aussi c'est pour mémoire que je les mets là. Elles ne gênent pas. Le seul point important est la version de la ligne 27. C'est celle de la DLL [System.Data] présente dans les références du projet :

Voilà. Nous sommes prêts. Nous exécutons le projet et nous obtenons la base [rdvmedecins-ef] suivante :

Ce sera notre base définitive. Il nous reste à mettre des données dedans.

La classe d'initialisation de la base peut être utilisée pour y insérer des données :

public class RdvMedecinsInitializer : DropCreateDatabaseIfModelChanges<RdvMedecinsContext>
  {
    // initialisation de la base
    public class RdvMedecinsInitializer : DropCreateDatabaseAlways<RdvMedecinsContext>
    {
      protected override void Seed(RdvMedecinsContext context)
      {
        base.Seed(context);
        // on initialise la base
        // les clients
        Client[] clients ={
        new Client { Titre = "Mr", Nom = "Martin", Prenom = "Jules" },
        new Client { Titre = "Mme", Nom = "German", Prenom = "Christine" },
        new Client { Titre = "Mr", Nom = "Jacquard", Prenom = "Jules" },
        new Client { Titre = "Mlle", Nom = "Bistrou", Prenom = "Brigitte" }
     };
        foreach (Client client in clients)
        {
          context.Clients.Add(client);
        }
        // les médecins
        Medecin[] medecins ={
        new Medecin { Titre = "Mme", Nom = "Pelissier", Prenom = "Marie" },
        new Medecin { Titre = "Mr", Nom = "Bromard", Prenom = "Jacques" },
        new Medecin { Titre = "Mr", Nom = "Jandot", Prenom = "Philippe" },
        new Medecin { Titre = "Mlle", Nom = "Jacquemot", Prenom = "Justine" }
     };
        foreach (Medecin medecin in medecins)
        {
          context.Medecins.Add(medecin);
        }
        // les créneaux horaires
        Creneau[] creneaux ={
        new Creneau{ Hdebut=8,Mdebut=0,Hfin=8,Mfin=20,Medecin=medecins[0]},
        new Creneau{ Hdebut=8,Mdebut=20,Hfin=8,Mfin=40,Medecin=medecins[0]},
        new Creneau{ Hdebut=8,Mdebut=40,Hfin=9,Mfin=0,Medecin=medecins[0]},
        new Creneau{ Hdebut=9,Mdebut=0,Hfin=9,Mfin=20,Medecin=medecins[0]},
        new Creneau{ Hdebut=9,Mdebut=20,Hfin=9,Mfin=40,Medecin=medecins[0]},
        new Creneau{ Hdebut=9,Mdebut=40,Hfin=10,Mfin=0,Medecin=medecins[0]},
        new Creneau{ Hdebut=10,Mdebut=0,Hfin=10,Mfin=20,Medecin=medecins[0]},
        new Creneau{ Hdebut=10,Mdebut=20,Hfin=10,Mfin=40,Medecin=medecins[0]},
        new Creneau{ Hdebut=10,Mdebut=40,Hfin=11,Mfin=0,Medecin=medecins[0]},
        new Creneau{ Hdebut=11,Mdebut=0,Hfin=11,Mfin=20,Medecin=medecins[0]},
        new Creneau{ Hdebut=11,Mdebut=20,Hfin=11,Mfin=40,Medecin=medecins[0]},
        new Creneau{ Hdebut=11,Mdebut=40,Hfin=12,Mfin=0,Medecin=medecins[0]},
        new Creneau{ Hdebut=14,Mdebut=0,Hfin=14,Mfin=20,Medecin=medecins[0]},
        new Creneau{ Hdebut=14,Mdebut=20,Hfin=14,Mfin=40,Medecin=medecins[0]},
        new Creneau{ Hdebut=14,Mdebut=40,Hfin=15,Mfin=0,Medecin=medecins[0]},
        new Creneau{ Hdebut=15,Mdebut=0,Hfin=15,Mfin=20,Medecin=medecins[0]},
        new Creneau{ Hdebut=15,Mdebut=20,Hfin=15,Mfin=40,Medecin=medecins[0]},
        new Creneau{ Hdebut=15,Mdebut=40,Hfin=16,Mfin=0,Medecin=medecins[0]},
        new Creneau{ Hdebut=16,Mdebut=0,Hfin=16,Mfin=20,Medecin=medecins[0]},
        new Creneau{ Hdebut=16,Mdebut=20,Hfin=16,Mfin=40,Medecin=medecins[0]},
        new Creneau{ Hdebut=16,Mdebut=40,Hfin=17,Mfin=0,Medecin=medecins[0]},
        new Creneau{ Hdebut=17,Mdebut=0,Hfin=17,Mfin=20,Medecin=medecins[0]},
        new Creneau{ Hdebut=17,Mdebut=20,Hfin=17,Mfin=40,Medecin=medecins[0]},
        new Creneau{ Hdebut=17,Mdebut=40,Hfin=18,Mfin=0,Medecin=medecins[0]},
        new Creneau{ Hdebut=8,Mdebut=0,Hfin=8,Mfin=20,Medecin=medecins[1]},
        new Creneau{ Hdebut=8,Mdebut=20,Hfin=8,Mfin=40,Medecin=medecins[1]},
        new Creneau{ Hdebut=8,Mdebut=40,Hfin=9,Mfin=0,Medecin=medecins[1]},
        new Creneau{ Hdebut=9,Mdebut=0,Hfin=9,Mfin=20,Medecin=medecins[1]},
        new Creneau{ Hdebut=9,Mdebut=20,Hfin=9,Mfin=40,Medecin=medecins[1]},
        new Creneau{ Hdebut=9,Mdebut=40,Hfin=10,Mfin=0,Medecin=medecins[1]},
        new Creneau{ Hdebut=10,Mdebut=0,Hfin=10,Mfin=20,Medecin=medecins[1]},
        new Creneau{ Hdebut=10,Mdebut=20,Hfin=10,Mfin=40,Medecin=medecins[1]},
        new Creneau{ Hdebut=10,Mdebut=40,Hfin=11,Mfin=0,Medecin=medecins[1]},
        new Creneau{ Hdebut=11,Mdebut=0,Hfin=11,Mfin=20,Medecin=medecins[1]},
        new Creneau{ Hdebut=11,Mdebut=20,Hfin=11,Mfin=40,Medecin=medecins[1]},
        new Creneau{ Hdebut=11,Mdebut=40,Hfin=12,Mfin=0,Medecin=medecins[1]},
      };
        foreach (Creneau creneau in creneaux)
        {
          context.Creneaux.Add(creneau);
        }
        // les Rdv
        context.Rvs.Add(new Rv { Jour = new System.DateTime(2012, 10, 8), Client = clients[0], Creneau = creneaux[0] });
      }

    }
  }

• ligne 6 : l'initialisation se passe dans la méthode [Seed]. Celle-ci existe dans la classe mère. Elle est ici redéfinie. L'argument est le contexte de persistance [RdvMedecinsContext] de l'application ;
• ligne 8 : l'argument est passé à la classe mère ; il est probable que celle-ci ouvre le contexte de persistance qu'on lui a passé car cette ouverture n'est plus nécessaire par la suite ;
• lignes 11-16 : création de 4 clients ;
• lignes 17-20 : ceux-ci sont ajoutés au contexte de persistance, plus exactement aux médecins de celui-ci. On notera la méthode [Add] qui permet cela. Il faut se rappeler ici la définition du contexte :

public class RdvMedecinsContext : DbContext
  {
    // les entités
    public DbSet<Medecin> Medecins { get; set; }
    public DbSet<Creneau> Creneaux { get; set; }
    public DbSet<Client> Clients { get; set; }
public DbSet<Rv> Rvs { get; set; }
...

On dit aussi que les clients ont été attachés au contexte, c'-à-d. qu'ils sont désormais gérés par EF. Avant ils en étaient détachés . Ils existaient en tant qu'objets mais n'étaient pas gérés par EF ;

• lignes 21-27 : création de 4 médecins ;
• lignes 28-31 : on les met dans le contexte de persistance ;
• lignes 33-70 : création de créneaux horaires. Lignes 34-57, pour le médecin medecins[0] , lignes 58-69, pour le médecin medecins[1] . Les autres médecins sont sans créneaux horaires ;
• lignes 71-74 : on met ces créneaux dans le contexte de persistance ;
• ligne 76 : création d'un rendez-vous pour le 1 ^er client avec le 1 ^er créneau horaire et sa mise dans le contexte de persistance.

Lorsqu'on exécute le projet, on obtient la base suivante :

Ci-dessus, on voit la table [CLIENTS] remplie.

Actuellement, les classes [Medecin] et [Client] sont quasi identiques. En fait si on enlève les champs ajoutés pour la gestion de la persistance avec EF 5, elles sont identiques. Nous allons les faire dériver d'une classe [Personne]. Ces deux entités deviennent alors les suivantes :

// une personne
  public abstract class Personne
  {
    // data
    [Key]
    [Column("ID")]
    public int? Id { get; set; }
    [Required]
    [MaxLength(5)]
    [Column("TITRE")]
    public string Titre { get; set; }
    [Required]
    [MaxLength(30)]
    [Column("NOM")]
    public string Nom { get; set; }
    [Required]
    [MaxLength(30)]
    [Column("PRENOM")]
    public string Prenom { get; set; }
    [Column("TIMESTAMP")]
    [Timestamp]
    public byte[] Timestamp { get; set; }

    // signature
    public override string ToString()
    {
      return String.Format("[{0},{1},{2},{3},{4}]", Id, Titre, Prenom, Nom, dump(Timestamp));
    }
    // signature courte
    public string ShortIdentity()
    {
      ...
    }

    // utilitaire
    private string dump(byte[] timestamp)
    {
      ...
    }

  }

  [Table("MEDECINS", Schema = "dbo")]
  public class Medecin : Personne
  {
    // les créneaux horaires du médecin
    public ICollection<Creneau> Creneaux { get; set; }
    // signature
    public override string ToString()
    {
      return String.Format("Medecin {0}", base.ToString());
    }
  }

[Table("CLIENTS", Schema = "dbo")]
    public class Client : Personne
  {
    // les Rvs du client
    public ICollection<Rv> Rvs { get; set; }
    // signature
    public override string ToString()
    {
      return String.Format("Client {0}", base.ToString());
    }
  }

Lorsqu'on exécute le projet, on obtient la même base. EF 5 a mappé les classes les plus basses de l'héritage chacune dans une table. En fait, EF 5 a différentes stratégies de génération de tables pour représenter l'héritage d'entités. Nous ne les présenterons pas ici. On pourra lire par exemple " Entity Framework Code First Inheritance : Table Per Hierarchy and Table Per Type ", à l'URL [http://www.codeproject.com/Articles/393228/Entity-Framework-Code-First-Inheritance-Table-Per].

Nous utiliserons désormais cette version des entités.

Il nous reste un détail à régler. La table [RVS] des rendez-vous est la suivante :

Cette table doit avoir une contrainte d'unicité : pour un jour donné, un créneau horaire d'un médecin ne peut être réservé qu'une fois pour un rendez-vous. En termes de table, cela signifie que le couple (JOUR,CRENEAU_ID) doit être unique. Je ne sais pas si cette contrainte peut être exprimée directement dans le code, soit sur les entités soit sur le contexte. C'est probable mais je n'ai pas vérifié. Nous allons prendre une autre démarche. Nous allons utiliser un client d'administration de SQL Server pour ajouter cette contrainte.

Avec " SQL Server Management Studio ", je n'ai pas trouvé de méthode simple pour ajouter cette contrainte hormis exécuter l'ordre SQL qui la crée :

• en [1] on crée une requête SQL pour la base [rdvmedecins-ef] ;
• en [2], la requête SQL qui crée la contrainte d'unicité ;
• en [3], l'exécution de cette requête a créé un nouvel index dans la table [RVS].

Il existe d'autres outils d'administration de SQL Server. Nous allons utiliser ici l'outil EMS SQL Manager for SQL Server Freeware [http://www.sqlmanager.net/fr/products/mssql/manager/download]. Une fois installé, nous le lançons :

• en [1], on enregistre une base de données ;
• en [2], on se connecte au serveur (local)  ;
• en [3], avec une authentification SQL Server ;
• en [4], sous l'identité sa  ;
• en [5], et le mot de passe sqlserver2012  ;
• en [6], on passe à l'étape suivante ;

• en [7], on choisit la base [rdvmedecins-ef] ;
• en [8], on termine l'assistant ;
• en [9], la base apparaît dans l'arborescence des bases. On s'y connecte [10] ;
• en [11], on est connecté.

" SQL Manager Lite for SQL Server " permet de créer la contrainte d'unicité sur la table [RVS].

• en [1], on voit la contrainte d'unicité que nous avons créée précédemment ;
• en [2], on la supprime ;
• en [3], l'indice correspondant à cette contrainte d'unicité a disparu.

On recrée la contrainte supprimée :

• en [1], on crée un nouvel index pour la table [RVS] ;
• en [2], on lui donne un nom ;
• en [3], c'est une contrainte d'unicité ;
• en [4], sur les colonnes JOUR et CRENEAU_ID ;

L'onglet DDL nous donne le code SQL qui va être exécuté :

• en [6], on compile l'ordre SQL ;

• en [7], on confirme ;
• en [8], le nouvel indice est apparu.

L'interface offerte par " SQL Manager Lite for SQL Server " est analogue à celle offerte par " SQL Server Management Studio ". On peut trouver des interfaces analogues pour les SGBD Oracle, PostgreSQL, Firebird, MySQL. Aussi continuerons-nous désormais avec cette famille d'outils d'administration de SGBD.

Pour avoir accès aux informations d'une table, il suffit de double-cliquer dessus :

Les informations sur la table sélectionnée sont disponibles dans des onglets. Ci-dessus, on voit l'onglet [Fields] de la table [CLIENTS]. L'onglet [Data] affiche le contenu de la table :

Nous avons notre base définitive. Nous exportons son script SQL afin de pouvoir la régénérer si besoin est.

• en [1], début de l'assistant ;
• en [2], le serveur ;
• en [3], la base de données qui va être exportée ;

• en [4], précisez le nom du fichier où sera enregistré le script SQL ;
• en [5], précisez son encodage ;
• en [6], précisez ce que vous voulez extraire (tables, contraintes, données) ;

• en [7], vous pouvez affiner le script qui va être généré ;
• en [8], terminez l'assistant.

Le script a été généré et chargé dans l'éditeur de script. Vous pouvez consulter le code SQL généré. Nous allons reconstruire la base de données à partir de ce script.

• en [1], on supprime la base ;
• en [2] et [3], on la recrée ;

• en [4], on s'authentifie ;
• en [5], on exécute le script SQL de création de la base ;

• en [6], on l'enregistre dans " SQL Manager " ;
• en [7], on se connecte à la base qui vient d'être créée ;

• en [8], la base n'a pour l'instant pas de tables ;
• en [9a], on ouvre un éditeur de script SQL ;

• en [9b], on ouvre le script SQL créé précédemment ;
• en [10], on l'exécute ;

• en [11], les tables ont été créées ;
• en [12], elles sont remplies ;

• en [14], nous retrouvons la contrainte d'unicité que nous avions créée pour la table [RVS].

Nous allons désormais travailler avec cette base existante. Si elle est détruite ou détériorée, nous savons la régénérer.

Nous avons une base remplie. Nous allons la vider. Nous créons une nouvelle classe [Erase.cs] dans le projet actuel [1] :

La classe [Erase] est la suivante :

using RdvMedecins.Models;

namespace RdvMedecins_01
{
  class Erase
  {
    static void Main(string[] args)
    {
      using (var context = new RdvMedecinsContext())
      {
        // on vide la base actuelle
        // les clients
        foreach (var client in context.Clients)
        {
          context.Clients.Remove(client);
        }
        // les médecins
        foreach (var medecin in context.Medecins)
        {
          context.Medecins.Remove(medecin);
        }
        // on sauve le contexte de persistance
        context.SaveChanges();
      }
    }
  }
}

• ligne 9 : les opérations sur un contexte de persistance se font toujours dans une clause [using]. Cela assure qu'à la sortie du [using], le contexte a été fermé ;
• ligne 13 : on parcourt le contexte des clients [context.Clients]. Tous les clients de la base vont être mis dans le contexte de persistance ;
• ligne 15 : pour chacun d'eux on fait l'opération [Remove] qui les supprime du contexte. En fait, ils sont toujours dans le contexte mais dans un état " supprimé " ;
• lignes 18-21 : on fait la même chose pour les médecins ;
• ligne 23 : on sauvegarde le contexte de persistance en base.

Lors de la sauvegarde du contexte en base, les entités du contexte qui :

• ont une clé primaire null font l'objet d'une opération SQL INSERT ;
• sont dans un état " supprimé " font l'objet d'une opération SQL DELETE ;
• sont dans un état " modifié " font l'objet d'une opération SQL UPDATE ;

Comme nous le constaterons ultérieurement, ces opérations SQL se font à l'intérieur d'une transaction. Si l'une d'elles échoue, tout ce qui a été fait précédemment est défait.

Faisons du programme [Erase] le nouvel objet de démarrage du projet [1] puis exécutons le projet.

Vérifions la base. On constatera que toutes les tables sont vides [2]. C'est étonnant, car nous avions demandé simplement la suppression des médecins et des clients. C'est par le jeu des clés étrangères que les autres tables ont été vidées en cascade.

La définition de la clé étrangère de la table [CRENEAUX] vers la table [MEDECINS] a été définie comme suit par le provider d'EF 5 :

• en [1], on sélectionne la table [CRENEAUX] ;
• en [2], on sélectionne l'onglet des clés étrangères ;
• en [3], on édite l'unique clé étrangère ;

• en [4], dans l'onglet DDL , la définition SQL de la contrainte de clé étrangère ;
• en [5], la clause ON DELETE CASCADE fait que la suppression d'un médecin entraîne la suppression des créneaux qui lui sont associés.

Les contraintes de clé étrangères de la table [RVS] sont définies de façon analogue :

ALTER TABLE [dbo].[RVS]
ADD CONSTRAINT [FK_dbo.RVS_dbo.CLIENTS_CLIENT_ID] FOREIGN KEY ([CLIENT_ID]) 
  REFERENCES [dbo].[CLIENTS] ([ID]) 
  ON UPDATE NO ACTION
  ON DELETE CASCADE
GO

• lignes 1-6 : supprimer un client supprimera là également les rendez-vous qui lui sont associés ;

ALTER TABLE [dbo].[RVS]
ADD CONSTRAINT [FK_dbo.RVS_dbo.CRENEAUX_CRENEAU_ID] FOREIGN KEY ([CRENEAU_ID]) 
  REFERENCES [dbo].[CRENEAUX] ([ID]) 
  ON UPDATE NO ACTION
  ON DELETE CASCADE
GO

• lignes 1-6 : supprimer un créneau supprimera également tous les rendez-vous qui lui sont associés.

Maintenant que nous avons vidé la base, nous allons la remplir de nouveau. Nous ajoutons au projet le programme [Fill.cs] [1].

Le programme [Fill.cs] est le suivant :

using RdvMedecins.Entites;
using RdvMedecins.Models;

namespace RdvMedecins_01
{
  class Fill
  {
    static void Main(string[] args)
    {
      using (var context = new RdvMedecinsContext())
      {
        // on vide la base actuelle
        foreach (var client in context.Clients)
        {
          context.Clients.Remove(client);
        }
        foreach (var medecin in context.Medecins)
        {
          context.Medecins.Remove(medecin);
        }
        // on la réinitialise
        // les clients
        Client[] clients ={
        new Client { Titre = "Mr", Nom = "Martin", Prenom = "Jules" },
        new Client { Titre = "Mme", Nom = "German", Prenom = "Christine" },
        new Client { Titre = "Mr", Nom = "Jacquard", Prenom = "Jules" },
        new Client { Titre = "Melle", Nom = "Bistrou", Prenom = "Brigitte" }
     };
        foreach (Client client in clients)
        {
          context.Clients.Add(client);
        }
        // les médecins
        Medecin[] medecins ={
        new Medecin { Titre = "Mme", Nom = "Pelissier", Prenom = "Marie" },
        new Medecin { Titre = "Mr", Nom = "Bromard", Prenom = "Jacques" },
        new Medecin { Titre = "Mr", Nom = "Jandot", Prenom = "Philippe" },
        new Medecin { Titre = "Melle", Nom = "Jacquemot", Prenom = "Justine" }
     };
        foreach (Medecin medecin in medecins)
        {
          context.Medecins.Add(medecin);
        }
        // les créneaux horaires
        Creneau[] creneaux ={
        new Creneau{ Hdebut=8,Mdebut=0,Hfin=8,Mfin=20,Medecin=medecins[0]},
        new Creneau{ Hdebut=8,Mdebut=20,Hfin=8,Mfin=40,Medecin=medecins[0]},
        new Creneau{ Hdebut=8,Mdebut=40,Hfin=9,Mfin=0,Medecin=medecins[0]},
        new Creneau{ Hdebut=9,Mdebut=0,Hfin=9,Mfin=20,Medecin=medecins[0]},
        new Creneau{ Hdebut=9,Mdebut=20,Hfin=9,Mfin=40,Medecin=medecins[0]},
        new Creneau{ Hdebut=9,Mdebut=40,Hfin=10,Mfin=0,Medecin=medecins[0]},
        new Creneau{ Hdebut=10,Mdebut=0,Hfin=10,Mfin=20,Medecin=medecins[0]},
        new Creneau{ Hdebut=10,Mdebut=20,Hfin=10,Mfin=40,Medecin=medecins[0]},
        new Creneau{ Hdebut=10,Mdebut=40,Hfin=11,Mfin=0,Medecin=medecins[0]},
        new Creneau{ Hdebut=11,Mdebut=0,Hfin=11,Mfin=20,Medecin=medecins[0]},
        new Creneau{ Hdebut=11,Mdebut=20,Hfin=11,Mfin=40,Medecin=medecins[0]},
        new Creneau{ Hdebut=11,Mdebut=40,Hfin=12,Mfin=0,Medecin=medecins[0]},
        new Creneau{ Hdebut=14,Mdebut=0,Hfin=14,Mfin=20,Medecin=medecins[0]},
        new Creneau{ Hdebut=14,Mdebut=20,Hfin=14,Mfin=40,Medecin=medecins[0]},
        new Creneau{ Hdebut=14,Mdebut=40,Hfin=15,Mfin=0,Medecin=medecins[0]},
        new Creneau{ Hdebut=15,Mdebut=0,Hfin=15,Mfin=20,Medecin=medecins[0]},
        new Creneau{ Hdebut=15,Mdebut=20,Hfin=15,Mfin=40,Medecin=medecins[0]},
        new Creneau{ Hdebut=15,Mdebut=40,Hfin=16,Mfin=0,Medecin=medecins[0]},
        new Creneau{ Hdebut=16,Mdebut=0,Hfin=16,Mfin=20,Medecin=medecins[0]},
        new Creneau{ Hdebut=16,Mdebut=20,Hfin=16,Mfin=40,Medecin=medecins[0]},
        new Creneau{ Hdebut=16,Mdebut=40,Hfin=17,Mfin=0,Medecin=medecins[0]},
        new Creneau{ Hdebut=17,Mdebut=0,Hfin=17,Mfin=20,Medecin=medecins[0]},
        new Creneau{ Hdebut=17,Mdebut=20,Hfin=17,Mfin=40,Medecin=medecins[0]},
        new Creneau{ Hdebut=17,Mdebut=40,Hfin=18,Mfin=0,Medecin=medecins[0]},
        new Creneau{ Hdebut=8,Mdebut=0,Hfin=8,Mfin=20,Medecin=medecins[1]},
        new Creneau{ Hdebut=8,Mdebut=20,Hfin=8,Mfin=40,Medecin=medecins[1]},
        new Creneau{ Hdebut=8,Mdebut=40,Hfin=9,Mfin=0,Medecin=medecins[1]},
        new Creneau{ Hdebut=9,Mdebut=0,Hfin=9,Mfin=20,Medecin=medecins[1]},
        new Creneau{ Hdebut=9,Mdebut=20,Hfin=9,Mfin=40,Medecin=medecins[1]},
        new Creneau{ Hdebut=9,Mdebut=40,Hfin=10,Mfin=0,Medecin=medecins[1]},
        new Creneau{ Hdebut=10,Mdebut=0,Hfin=10,Mfin=20,Medecin=medecins[1]},
        new Creneau{ Hdebut=10,Mdebut=20,Hfin=10,Mfin=40,Medecin=medecins[1]},
        new Creneau{ Hdebut=10,Mdebut=40,Hfin=11,Mfin=0,Medecin=medecins[1]},
        new Creneau{ Hdebut=11,Mdebut=0,Hfin=11,Mfin=20,Medecin=medecins[1]},
        new Creneau{ Hdebut=11,Mdebut=20,Hfin=11,Mfin=40,Medecin=medecins[1]},
        new Creneau{ Hdebut=11,Mdebut=40,Hfin=12,Mfin=0,Medecin=medecins[1]},
      };
        foreach (Creneau creneau in creneaux)
        {
          context.Creneaux.Add(creneau);
        }
        // les Rdv
        context.Rvs.Add(new Rv { Jour = new System.DateTime(2012, 10, 8), Client = clients[0], Creneau = creneaux[0] });
        // on sauve le contexte de persistance
        context.SaveChanges();
      }
    }
  }
}

• ligne 10 : on ouvre le contexte de persistance ;
• lignes 13-20 : les lignes des tables [CLIENTS] et [MEDECINS] sont mises dans le contexte puis supprimées de celui-ci. Nous venons de voir que cela vidait totalement la base ;
• lignes 22-88 : des éléments sont ajoutés au contexte de persistance. Ils ont tous leur clé primaire à null . Ils seront donc insérés dans la base ;
• ligne 90 : les changements opérés sur le contexte sont synchronisés avec la base. Celle-ci va faire l'objet d'une série d'opérations SQL DELETE suivie d'une série d'opérations SQL INSERT ;

On fait du programme [Fill], le nouvel objet de démarrage du projet [1] puis on exécute ce dernier.

On constate en [2] que les tables ont été remplies.

Nous allons maintenant afficher le contenu de la base à l'aide de requêtes LINQ to Entity . LINQ ( L anguage IN tegrated Q uery) est apparu avec le framework .NET 3.5 en 2007. Il apparaît comme une extension des langages .NET, c.a.d qu'il est intégré au langage et sa syntaxe est vérifiée par le compilateur. Il permet de requêter différentes collections avec une syntaxe présentant des similitudes avec le langage SQL (Structured Query Language) de requêtage des bases de données. Il existe différentes moutures de LINQ :

• LINQ to Object, pour requêter des collections en mémoire ;
• LINQ to XML, pour requêter du XML ;
• LINQ to Entity, pour requêter des bases de données ;

Pour exister, LINQ s'appuie sur de nombreuses extensions faites aux langages .NET. Celles-ci peuvent être utilisées en-dehors de LINQ. Nous n'allons pas les présenter mais simplement donner deux références où le lecteur trouvera une description approfondie de LINQ :

• LINQ in Action , Fabrice Marguerie, Steve Eichert, Jim Wooley aux éditions Manning ;
• LINQ pocket reference , Joseph et Ben Albahari aux éditions O'Reilly.

J'ai lu le premier et l'ai trouvé excellent. Je n'ai pas lu le second mais ai lu des mêmes auteurs "  C# 3.0 in a nutshell  " à la sortie de LINQ. J'ai trouvé ce livre très au-dessus de la moyenne des livres que j'ai l'habitude de lire. Il semble que les autres livres de ces deux auteurs soient du même niveau. Nous allons par ailleurs utiliser LINQPad , un outil d'apprentissage de LINQ écrit par Joseph Albahari.

Nous allons afficher les entités présentes dans la base. Pour cela, nous ajoutons à leurs classes deux méthodes d'affichage. Commençons par l'entité [Medecin] :

// un médecin
  public class Medecin
  {
    // data
    [Key]
    [Column("ID")]
    public int? Id { get; set; }
    [Required]
    [MaxLength(5)]
    [Column("TITRE")]
    public string Titre { get; set; }
    [Required]
    [MaxLength(30)]
    [Column("NOM")]
    public string Nom { get; set; }
    [Required]
    [MaxLength(30)]
    [Column("PRENOM")]
    public string Prenom { get; set; }
    // les créneaux horaires du médecin
    public ICollection<Creneau> Creneaux { get; set; }
    [Column("TIMESTAMP")]
    [Timestamp]
    public byte[] Timestamp { get; set; }

    // signature
    public override string ToString()
    {
      return String.Format("Medecin[{0},{1},{2},{3},{4}]", Id, Titre, Prenom, Nom, dump(Timestamp));
    }
    // signature courte
    public string ShortIdentity()
    {
      return ToString();
    }

    // utilitaire
    private string dump(byte[] timestamp){
      string str = "";
      foreach (byte b in timestamp)
      {
        str += b;
      }
      return str;
    }
  }

• lignes 27-30 : la méthode ToString de la classe. On notera qu'elle n'affiche pas la collection de la ligne 21 ;
• lignes 32-37 : la méthode ShortIdentity qui fait la même chose.

Il nous faut ici expliquer les notions de Lazy et Eager Loading pour mesurer l'impact des deux méthodes précédentes. Nous avons vu qu'une entité pouvait avoir des dépendances sur une autre entité. Elles sont de deux natures :

• de un à plusieurs , comme ci-dessus où un médecin est relié à plusieurs créneaux horaires ;
• de plusieurs à un , comme dans l'entité [Creneau] ci-dessous où un plusieurs créneaux sont reliés au même médecin ;

public class Creneau
  {
    // data
    ...
    [Required]
    [Column("MEDECIN_ID")]
    public int MedecinId { get; set; }
    [Required]
    [ForeignKey("MedecinId")]
    public virtual Medecin Medecin { get; set; }
    ...
  }

Lorsque les dépendances sont chargées en même temps que les entités auxquelles elles sont attachées, on parle d' Eager Loading . Sinon, on parle de Lazy Loading  : les dépendances ne sont chargées que lorsqu'elles sont référencées la première fois. Par défaut, EF 5 utilise le Lazy Loading  : les dépendances ne sont pas chargées en même temps que l'entité.

Voyons notre méthode [ToString] ci-dessus :

// les créneaux horaires du médecin
    public ICollection<Creneau> Creneaux { get; set; }
    
    // signature
    public override string ToString()
    {
      return String.Format("Medecin[{0},{1},{2},{3},{4}]", Id, Titre, Prenom, Nom, dump(Timestamp));
    }
    // signature courte
    public string ShortIdentity()
    {
      return ToString();
}

La méthode [ToString] n'affiche pas la dépendance [Creneaux] de la ligne 2. Si elle l'avait fait, elle aurait alors forcé le chargement de tous les créneaux du médecin avant son exécution. C'est pour éviter ce chargement coûteux que la dépendance n'a pas été incluse dans la signature de l'entité. De façon générale, nous allons inclure deux signatures dans chaque entité :

• une méthode ToString qui affichera l'entité et ses éventuelles dépendances plusieurs à un . Comme il vient d'être expliqué cela provoquera le chargement de la dépendance ;
• une méthode ShortIdentity qui ne référencera aucune dépendance. Il n'y aura donc aucun chargement de dépendance ;

Les méthodes d'affichage des autres entités seront les suivantes :

L'entité [Client] :

public class Client
  {
    // data
    ...
    // les Rvs du client
    public ICollection<Rv> Rvs { get; set; }
    
    // signature
    public override string ToString()
    {
      return String.Format("Client[{0},{1},{2},{3},{4}]", Id, Titre, Prenom, Nom, dump(Timestamp));
    }
    // signature courte
    public string ShortIdentity()
    {
      return ToString();
    }

}

• lignes 9-12 : la méthode [ToString] n'affiche pas la dépendance de la ligne 6 ;

L'entité [Creneau] :

public class Creneau
  {
    ...
    [Required]
    [Column("MEDECIN_ID")]
    public int MedecinId { get; set; }
    [Required]
    [ForeignKey("MedecinId")]
    public virtual Medecin Medecin { get; set; }
    // les Rvs du créneau
    public ICollection<Rv> Rvs { get; set; }
    
    // signature
    public override string ToString()
    {
      return String.Format("Creneau[{0},{1},{2},{3},{4}, {5}]", Id, Hdebut, Mdebut, Hfin, Mfin, Medecin, dump(Timestamp));
    }
    // signature courte
    public string ShortIdentity()
    {
      return String.Format("Creneau[{0},{1},{2},{3},{4}, {5}, {6}]", Id, Hdebut, Mdebut, Hfin, Mfin, Timestamp, MedecinId, dump(Timestamp));
    }
  }

• ligne 16 : la méthode [ToString] référence la dépendance de la ligne 9. Cela va forcer son chargement ;
• ligne 11 : la dépendance [Rvs] n'est pas référencée. Elle ne sera pas chargée ;
• lignes 21-22 : la méthode [ShortIdentity] ne référence plus la référence [Medecin] de la ligne 9. Celle-ci ne sera donc pas chargée.

L'entité [Rv] :

public class Rv
  {
    // data
    ...
    [Column("CLIENT_ID")]
    public int ClientId { get; set; }
    [ForeignKey("ClientId")]
    [Required]
    public virtual Client Client { get; set; }
    [Column("CRENEAU_ID")]
    public int CreneauId { get; set; }
    [ForeignKey("CreneauId")]
    [Required]
    public virtual Creneau Creneau { get; set; }

    // signature
    public override string ToString()
    {
      return String.Format("Rv[{0},{1},{2},{3},{4}]", Id, Jour, Client, Creneau, dump(Timestamp));
    }
    // signature courte
    public string ShortIdentity()
    {
      return String.Format("Rv[{0},{1},{2},{3},{4}]", Id, Jour, ClientId, CreneauId, dump(Timestamp));
    }

  }

• lignes 17-20 : la méthode [ToString] référence les dépendances des lignes 9 et 14. Cela va forcer leur chargement ;
• lignes 17-20 : la méthode [ShortIdentity] évite cela et donc les dépendances ne seront pas chargées.

En conclusion, on prêtera attention aux méthodes [ToString] des entités. Si on n'y prête pas attention, afficher une table peut charger la moitié de la base si la table a de nombreuses dépendances.

Ceci expliqué, on écrit le nouveau code [Dump.cs] suivant :

using RdvMedecins.Entites;
using RdvMedecins.Models;
using System;
using System.Linq;

namespace RdvMedecins_01
{
  class Dump
  {
    static void Main(string[] args)
    {
      // dump de la base
      using (var context = new RdvMedecinsContext())
      {
        // les clients
        Console.WriteLine("Clients--------------------------------------");
        var clients = from client in context.Clients select client;
        foreach (Client client in clients)
        {
          Console.WriteLine(client);
        }
        // les médecins
        Console.WriteLine("Médecins--------------------------------------");
        var medecins = from medecin in context.Medecins select medecin;
        foreach (Medecin medecin in medecins)
        {
          Console.WriteLine(medecin);
        }
        // les créneaux horaires
        Console.WriteLine("Créneaux horaires--------------------------------------");
        var creneaux = from creneau in context.Creneaux select creneau;
        foreach (Creneau creneau in creneaux)
        {
          Console.WriteLine(creneau);
        }
        // les Rdvs
        Console.WriteLine("Rendez-vous--------------------------------------");
        var rvs = from rv in context.Rvs select rv;
        foreach (Rv rv in rvs)
        {
          Console.WriteLine(rv);
        }
      }
    }
  }
}

Nous allons expliquer les lignes 17-21 qui affiche les entités [Client]. L'explication donnée vaudra pour les autres entités.

// les clients
        Console.WriteLine("Clients--------------------------------------");
        var clients = from client in context.Clients select client;
        foreach (Client client in clients)
        {
          Console.WriteLine(client);
}

• ligne 3 : le mot clé var a été introduit avec C# 3.0. Il permet d'éviter d'indiquer le type précis d'une variable. Le compilateur déduit alors celui-ci du type de l'expression affectée à la variable ;
• ligne 3 : l'expression affectée à la variable clients est une requête LINQ to Entity . On y reconnaît des mots clés du langage SQL portés dans LINQ. La syntaxe utilisée ici est la suivante :

from variable in DbSet select variable

Une syntaxe plus générale de LINQ est

from variable in collection select variable

La collection va être parcourue et pour chaque élément de celle-ci, la variable va être évaluée. Ceci n'est fait que lorsque la variable [clients] de la ligne 3 va être énumérée par le for / each des lignes 4-7. Tant que ceci n'est pas fait, la variable [clients] n'est qu'une requête non évaluée ;

• ligne 4 : la requête [clients] est énumérée. Cela va forcer l'évaluation de la requête. Les lignes de la table [CLIENTS] vont être amenées tour à tour dans le contexte de persistance ;
• ligne 6 : la méthode [ToString] de l'entité [Client] est utilisée pour l'affichage. Il n'y a aucun chargement de dépendances ;

Passons aux lignes suivantes du code :

• lignes 24-28 : les lignes de la table [MEDECINS] sont amenées dans le contexte de persistance et affichées. Il n'y a aucun chargement de dépendances ;
• lignes 31-35 : les lignes de la table [CRENEAUX] sont amenées dans le contexte de persistance et affichées. Nous avons vu que la méthode [ToString] de cette entité affichait la dépendance [Medecin]. Or celle-ci est déjà chargée. Il n'y aura donc pas de nouveau chargement ;
• lignes 38-42 : les lignes de la table [RVS] sont amenées dans le contexte de persistance et affichées. Nous avons vu que la méthode [ToString] de cette entité affichait les dépendances [Client] et [Creneau]. Or celles-ci sont déjà chargées. Il n'y aura donc pas de nouveaux chargements.

On notera que l'ordre d'affichage n'est pas neutre. Si on avait voulu afficher d'abord les entités [Rv], la méthode [ToString] de celle-ci aurait provoqué le chargement des entités [Client] et [Creneau] liées à ces rendez-vous. Les autres n'auraient pas été chargées. Elles l'auraient été plus tard dans un autre affichage. Cela a un impact sur les performances. Le code précédent a besoin de quatre ordres SQL pour faire afficher toutes les entités. Supposons maintenant qu'on exploite d'abord la tables [RVS] des rendez-vous. Une première requête SQL est nécessaire pour la table [RVS]. Ensuite, la méthode [ToString] de l'entité [Rv] va provoquer le chargement éventuel des entités [Client] et [Creneau] associées. Il faut une requête SQL pour chacune. En supposant qu'il y ait N2 clients et N3 créneaux et que toutes ces entités soient référencées dans la table [RVS], l'affichage de celle-ci nécessitera 1+N2+N3 requêtes SQL. Donc, on n'est moins performant que dans la version étudiée. Pour afficher la table [RVS] avec ses dépendances, une jointure entre tables serait nécessaire. Il est possible de la réaliser avec LINQ. Nous y reviendrons sur un exemple. Pour l'instant, nous nous rappellerons que nous devons prêter attention aux requêtes SQL sous-jacentes à notre code LINQ.

On paramètre le projet pour exécuter ce nouveau code [1] et [2] puis on l'exécute :

L'affichage console est le suivant :

Clients--------------------------------------
Client[9,Mr,Jules,Martin,000000844]
Client[10,Mme,Christine,German,000000845]
Client[11,Mr,Jules,Jacquard,000000846]
Client[12,Melle,Brigitte,Bistrou,000000847]
Médecins--------------------------------------
Medecin[9,Mme,Marie,Pelissier,000000848]
Medecin[10,Mr,Jacques,Bromard,000000873]
Medecin[11,Mr,Philippe,Jandot,000000886]
Medecin[12,Melle,Justine,Jacquemot,000000887]
Créneaux horaires--------------------------------------
Creneau[73,8,0,8,20, Medecin[9,Mme,Marie,Pelissier,000000848],000000849]
Creneau[74,8,20,8,40, Medecin[9,Mme,Marie,Pelissier,000000848],000000850]
Creneau[75,8,40,9,0, Medecin[9,Mme,Marie,Pelissier,000000848],000000851]
Creneau[76,9,0,9,20, Medecin[9,Mme,Marie,Pelissier,000000848],000000852]
Creneau[77,9,20,9,40, Medecin[9,Mme,Marie,Pelissier,000000848],000000853]
Creneau[78,9,40,10,0, Medecin[9,Mme,Marie,Pelissier,000000848],000000854]
Creneau[79,10,0,10,20, Medecin[9,Mme,Marie,Pelissier,000000848],000000855]
Creneau[80,10,20,10,40, Medecin[9,Mme,Marie,Pelissier,000000848],000000856]
Creneau[81,10,40,11,0, Medecin[9,Mme,Marie,Pelissier,000000848],000000857]
Creneau[82,11,0,11,20, Medecin[9,Mme,Marie,Pelissier,000000848],000000858]
Creneau[83,11,20,11,40, Medecin[9,Mme,Marie,Pelissier,000000848],000000859]
Creneau[84,11,40,12,0, Medecin[9,Mme,Marie,Pelissier,000000848],000000860]
Creneau[85,14,0,14,20, Medecin[9,Mme,Marie,Pelissier,000000848],000000861]
Creneau[86,14,20,14,40, Medecin[9,Mme,Marie,Pelissier,000000848],000000862]
Creneau[87,14,40,15,0, Medecin[9,Mme,Marie,Pelissier,000000848],000000863]
Creneau[88,15,0,15,20, Medecin[9,Mme,Marie,Pelissier,000000848],000000864]
Creneau[89,15,20,15,40, Medecin[9,Mme,Marie,Pelissier,000000848],000000865]
Creneau[90,15,40,16,0, Medecin[9,Mme,Marie,Pelissier,000000848],000000866]
Creneau[91,16,0,16,20, Medecin[9,Mme,Marie,Pelissier,000000848],000000867]
Creneau[92,16,20,16,40, Medecin[9,Mme,Marie,Pelissier,000000848],000000868]
Creneau[93,16,40,17,0, Medecin[9,Mme,Marie,Pelissier,000000848],000000869]
Creneau[94,17,0,17,20, Medecin[9,Mme,Marie,Pelissier,000000848],000000870]
Creneau[95,17,20,17,40, Medecin[9,Mme,Marie,Pelissier,000000848],000000871]
Creneau[96,17,40,18,0, Medecin[9,Mme,Marie,Pelissier,000000848],000000872]
Creneau[97,8,0,8,20, Medecin[10,Mr,Jacques,Bromard,000000873],000000874]
Creneau[98,8,20,8,40, Medecin[10,Mr,Jacques,Bromard,000000873],000000875]
Creneau[99,8,40,9,0, Medecin[10,Mr,Jacques,Bromard,000000873],000000876]
Creneau[100,9,0,9,20, Medecin[10,Mr,Jacques,Bromard,000000873],000000877]
Creneau[101,9,20,9,40, Medecin[10,Mr,Jacques,Bromard,000000873],000000878]
Creneau[102,9,40,10,0, Medecin[10,Mr,Jacques,Bromard,000000873],000000879]
Creneau[103,10,0,10,20, Medecin[10,Mr,Jacques,Bromard,000000873],000000880]
Creneau[104,10,20,10,40, Medecin[10,Mr,Jacques,Bromard,000000873],000000881]
Creneau[105,10,40,11,0, Medecin[10,Mr,Jacques,Bromard,000000873],000000882]
Creneau[106,11,0,11,20, Medecin[10,Mr,Jacques,Bromard,000000873],000000883]
Creneau[107,11,20,11,40, Medecin[10,Mr,Jacques,Bromard,000000873],000000884]
Creneau[108,11,40,12,0, Medecin[10,Mr,Jacques,Bromard,000000873],000000885]
Rendez-vous--------------------------------------
Rv[3,08/10/2012 00:00:00,Client[9,Mr,Jules,Martin,000000844],Creneau[73,8,0,8,20
, Medecin[9,Mme,Marie,Pelissier,000000848],000000849],000000888]
Appuyez sur une touche pour continuer...

Nous avons utilisé ci-dessus, des requêtes LINQ to Entity pour afficher le contenu des tables de la base de données. Joseph Albahari a écrit un programme d'apprentissage des différentes formes de LINQ. Nous le présentons maintenant.

LINQPad est disponible à l'URL suivante [ http://www.linqpad.net/ ]. Une fois installé, nous le lançons [1] :

Le débutant LINQ pourra s'initier avec les exemples de l'onglet [Samples] [2] qui montrent de très nombreux exemples. Sélectionnons l'exemple [3] qui s'affiche alors dans une autre fenêtre [4]. Le code complet de l'exemple est celui-ci :

// Now for a simple LINQ-to-objects query expression (notice no semicolon):

from word in "The quick brown fox jumps over the lazy dog".Split()
orderby word.Length
select word


// Feel free to edit this... (no-one's watching!) You'll be prompted to save any
// changes to a separate file.
//
// Tip:  You can execute part of a query by highlighting it, and then pressing F5.

Les lignes 3-5 sont un exemple de requête LINQ to Object. La requête LINQ suit la syntaxe :

from variable in collection orderby élément1 select élément2

• variable désigne l'élément courant de la collection. Dans notre exemple, cette collection est la liste de mots résultats de la chaîne splittée ;
• la collection est ordonnée selon le paramètre élément1 de orderby . Dans notre exemple, la collection de mots sera ordonnée selon leur longueur ;
• le mot clé select désigne ce qu'on veut retirer de l'élément courant variable de la collection. Dans notre exemple, ce sera le mot.

Exécutons cette requête LINQ :

• en [1] : une expression LINQ est exécutée par [F5] ou bien via le bouton d'exécution ;
• en [2] : l'affichage. Les mots sont affichés dans l'ordre de leur longueur. Ce simple exemple montre la puissance de LINQ ;
• en [3], il est possible de télécharger d'autres exemples, notamment ceux du livre " LINQ in action " [4] ;

• en [5], nous choisissons un exemple du livre ;

string[] words = { "hello", "wonderful", "linq", "beautiful", "world" };

// Group words by length
var groups =
  from word in words
  orderby word ascending
  group word by word.Length into lengthGroups
  orderby lengthGroups.Key descending
  select new { Length = lengthGroups.Key, Words = lengthGroups };

// Print each group out
foreach (var group in groups)
{
  Console.WriteLine("Words of length " + group.Length);
  foreach (string word in group.Words)
    Console.WriteLine("  " + word);
}

• ligne 4 : une nouvelle requête LINQ avec de nouveaux mots clés ;
• ligne 5 : la collection requêtée est le tableau de mots de la ligne 1 ;
• ligne 6 : la collection est triée dans l'ordre alphabétique des mots ;
• ligne 7 : la collection est regroupée dans (mot clé into ) une nouvelle collection lengthGroups . lengthGroups.Key représente le facteur de regroupement (mot clé by ), ici la longueur des mots. lengthGroups rassemble les mots ayant le même facteur de regroupement donc la même longueur ;
• ligne 8 : la collection lengthGroups est ordonnée par clé de regroupement descendant, donc ici par taille décroissante des mots ;
• ligne 9 : de cette collection, on produit de nouveaux objets (classes anonymes) ayant deux champs :
• Length  : la longueur des mots,
• Words  : les mots ayant cette longueur ;

Ici, on voit particulièrement l'intérêt du mot clé var de la ligne 4. Parce qu'on a utilisé une classe anonyme ligne 9, on ne sait pas désigner le type de la variable groups . Le compilateur lui, va donner un nom interne à la classe anonyme et va typer avec, la variable groups . Il sera capable ensuite de dire si la variable groups est utilisée correctement

• ligne 12 : parcours de la requête de la ligne 4. Ce n'est qu'à ce moment qu'elle est évaluée. On se rappelle que son exécution va produire une collection d'objets, précisés ligne 9 ;
• ligne 14 : on affiche la propriété Length de l'élément courant, donc une longueur de mots ;
• lignes 15-17 : on affiche chaque élément de la collection de la propriété Words , donc l'ensemble des mots ayant la longueur affichée précédemment.

Lorsque nous exécutons cette requête, nous obtenons le résultat suivant dans LINQPad :

Maintenant que nous avons vu quelques exemples de requêtes [LINQ to Object], voyons des requêtes [LINQ to Entity] qui vont nous permettre de requêter des bases de données. Nous allons tout d'abord nous connecter à la base de données SQL Server que nous avons créée et remplie :

• en [1], on ajoute une connexion à une base de données ;
• en [2], les moyens d'accès à la source de données. Pour accéder à la base SQL Server, nous utiliserons [LINQPad Driver] ;
• en [3], il est également possible de récupérer un contexte de persistance [DbContext] défini dans un assembly .exe ou .dll (option 3). Malheureusement, à ce jour (8 octobre 2012), Entity Framework 5 n'est pas supporté ;
• en [4], il est possible de télécharger des pilotes pour d'autres SGBD que SQL Server ;
• en [5], on téléchargera le driver pour les SGBD MySQL et Oracle ;

• en [6], le pilote téléchargé ;
• en [7], nous nous connectons à une base SQL Server ;

• en [8], la base est sur le serveur de nom (local) ;
• en [9], on se connecte avec l'authentification sa / sqlserver2012 ;
• en [10], à la base [rdvmedecins-ef] que nous avons créée ;
• en [11], on peut tester la connexion ;
• en [12], on termine l'assistant ;
• en [13], la connexion apparaît dans LINQPad.

Les entités ont été créées à partir de la table [rdvmedecins-ef]. Ce sont les suivantes :

• en [1], [CLIENTS] représente l'ensemble des entités [Client]. Chaque entité a :
• les propriétés (ID, TITRE, NOM, PRENOM, TIMESTAMP),
• une relation 1 à plusieurs [CLIENTRVS] ;
• en [2], [CRENEAUXes] représente l'ensemble des entités [Creneau]. Chaque entité a :
• les propriétés (ID, HDEBUT, MDEBUT, HFIN, MFIN, MEDECIN_ID, TIMESTAMP),
• une relation 1 à plusieurs [CRENEAURVS],
• une relation plusieurs à 1 [MEDECIN] ;
• en [3], l'entité [MEDECINS] représente l'ensemble des entités [Medecin]. Chaque entité a :
• les propriétés (ID, TITRE, NOM, PRENOM, TIMESTAMP),
• une relation 1 à plusieurs [MEDECINCRENEAUXes] ;
• en [4], l'entité [RVS] représente l'ensemble des entités [Rv]. Chaque entité a :
• les propriétés (ID, JOUR, CLIET_ID, CRENEAU_ID, TIMESTAMP),
• une relation plusieurs à 1 [CLIENT],
• une relation plusieurs à 1 [CRENEAU].

On notera que les noms des propriétés ci-dessus sont différentes des noms que nous avons utilisés jusqu'à maintenant. Cela importe peu. Nous voulons juste apprendre les principes de base du requêtage sur base de données.

Voyons comment nous pouvons requêter cette base d'entités. Par exemple, nous voulons la liste des médecins ordonnée par leur TITRE et NOM :

• en [1], on crée une nouvelle requête ;
• en [2], le texte de la requête ;

• en [3], le résultat de la requête ;
• en [4], la même requête avec des expressions lambda . Une requête avec des expressions lambda est moins lisible qu'une requête texte et on pourrait vouloir s'en passer. Elles sont cependant parfois indispensables car elles permettent certaines choses que les requêtes texte ne permettent pas. Une expression lambda désigne une fonction à un paramètre d'entrée a et un paramètre de sortie b , sous la forme a=>b . La méthode OrderBy ci-dessus admet une fonction lambda comme unique paramètre. Celle-ci lui fournit le paramètre selon lequel doit être ordonnée une collection. Ainsi MEDECINS.OrderBy(m=>m.TITRE) est la liste des médecins ordonnée par les titres. Il faut lire l'instruction comme un pipe-line sur une collection. La collection des médecins est fournie en entrée à la méthode OrderBy . Celle-ci va exploiter les entités [Medecin] une par une. Dans l'expression lambda m=>m.TITRE, m représente l'entrée de la fonction lambda. On peut la nommer comme on veut. Ici, l'entrée de la fonction lambda sera une entité [Medecin]. La fonction m=>m.TITRE se lit comme suit : si j'appelle m mon entrée (une entité [Medecin]) alors ma sortie est m.TITRE , donc le titre du médecin. MEDECINS.OrderBy(m=>m.TITRE) est a son tour une collection, la collection des médecins ordonnée par les titres. Cette nouvelle collection peut alimenter une autre méthode, dans l'exemple la méthode ThenBy . Celle-ci fonctionne sur le même principe. Elle sert à indiquer des paramètres supplémentaires pour le tri de la collection.

Lire le code lambda équivalent au code texte que nous tapons habituellement est une bonne façon de l'apprendre ;

• en [5], l'ordre SQL émis sur la base. Là encore, on lira attentivement ce code. Il permet d'évaluer le coût réel d'une requête LINQ.

Dans la suite, nous présentons quelques exemples de requête LINQ. A chaque fois, nous montrons les résultats affichés et les codes lambda et SQL équivalents. Pour comprendre ces requêtes, il faut rappeler les relations plusieurs à un qui relient les entités les unes aux autres. C'est par elles qu'on navigue d'une entité à l'autre. On les appelle des propriétés navigationnelles .

// les clients dont le titre est Mr classés par ordre décroissant des noms

Résultats  :

from client in CLIENTS where client.TITRE=="Mr" orderby client.NOM descending  select client

CLIENTS
.Where (client => (client.TITRE == "Mr"))
.OrderByDescending (client => client.NOM)

-- Region Parameters
DECLARE @p0 NVarChar(1000) = 'Mr'
-- EndRegion
SELECT [t0].[ID], [t0].[TITRE], [t0].[NOM], [t0].[PRENOM], [t0].[TIMESTAMP]
FROM [CLIENTS] AS [t0]
WHERE [t0].[TITRE] = @p0
ORDER BY [t0].[NOM] DESC

// tous les créneaux horaires avec le médecin associé

Résultats (partiels)  :

from creneau in CRENEAUXes select new { hd=creneau.HDEBUT, md=creneau.MDEBUT, hf=creneau.HFIN, mf=creneau.MFIN, medecin=creneau.MEDECIN}

Lambda

SELECT [t0].[HDEBUT] AS [hd], [t0].[MDEBUT] AS [md], [t0].[HFIN] AS [hf], [t0].[MFIN] AS [mf], [t1].[ID], [t1].[TITRE], [t1].[NOM], [t1].[PRENOM], [t1].[TIMESTAMP]
FROM [CRENEAUX] AS [t0]
INNER JOIN [MEDECINS] AS [t1] ON [t1].[ID] = [t0].[MEDECIN_ID]

// tous les rv avec le client et le médecin associés

Résultats  :

from rv in RVS select new { rv=rv.CLIENT, medecin=rv.CRENEAU.MEDECIN}

Lambda

SELECT [t1].[ID], [t1].[TITRE], [t1].[NOM], [t1].[PRENOM], [t1].[TIMESTAMP], [t3].[ID] AS [ID2], [t3].[TITRE] AS [TITRE2], [t3].[NOM] AS [NOM2], [t3].[PRENOM] AS [PRENOM2], [t3].[TIMESTAMP] AS [TIMESTAMP2]
FROM [RVS] AS [t0]
INNER JOIN [CLIENTS] AS [t1] ON [t1].[ID] = [t0].[CLIENT_ID]
INNER JOIN [CRENEAUX] AS [t2] ON [t2].[ID] = [t0].[CRENEAU_ID]
INNER JOIN [MEDECINS] AS [t3] ON [t3].[ID] = [t2].[MEDECIN_ID]

// les médecins n'ayant pas de Rdv

Résultats  :

Lambda

SELECT [t0].[ID], [t0].[TITRE], [t0].[NOM], [t0].[PRENOM], [t0].[TIMESTAMP]
FROM [MEDECINS] AS [t0]
WHERE NOT (EXISTS(
    SELECT NULL AS [EMPTY]
    FROM [RVS] AS [t1]
    INNER JOIN [CRENEAUX] AS [t2] ON [t2].[ID] = [t1].[CRENEAU_ID]
    INNER JOIN [MEDECINS] AS [t3] ON [t3].[ID] = [t2].[MEDECIN_ID]
    WHERE [t3].[ID] = [t0].[ID]
    ))

Il n'y a pas de requête LINQ pour cette demande. Il faut passer par des expressions lambda. Celle-ci se lit de la façon suivante : je prends la collection des médecins (MEDECINS) et je ne garde (Where) que les médecins (m) tels que je ne suis pas capable de trouver dans la collection des rendez-vous (RVS) un rendez-vous (rv) avec ce médecin (m).

// créneaux horaires de Mme Pélissier

Résultats (partiels)  :

from creneau in CRENEAUXes where creneau.MEDECIN.NOM=="Pelissier" select creneau

-- Region Parameters

DECLARE @p0 NVarChar(1000) = 'Pelissier'

DECLARE @p1 DateTime = '2012-10-08 00:00:00.000'

-- EndRegion

SELECT COUNT(*) AS [value]

FROM [RVS] AS [t0]

INNER JOIN [CRENEAUX] AS [t1] ON [t1].[ID] = [t0].[CRENEAU_ID]

INNER JOIN [MEDECINS] AS [t2] ON [t2].[ID] = [t1].[MEDECIN_ID]

WHERE ([t2].[NOM] = @p0) AND ([t0].[JOUR] = @p1)

Lambda

// nombre de Rdv de Mme Pélissier le 08/10/2012

Résultats  :

(from rv in RVS where rv.CRENEAU.MEDECIN.NOM=="Pelissier" && rv.JOUR==new DateTime(2012,10,08)  select rv).Count()

-- Region Parameters

DECLARE @p0 NVarChar(1000) = 'Pelissier'

DECLARE @p1 DateTime = '2012-10-08 00:00:00.000'

-- EndRegion

SELECT COUNT(*) AS [value]

FROM [RVS] AS [t0]

INNER JOIN [CRENEAUX] AS [t1] ON [t1].[ID] = [t0].[CRENEAU_ID]

INNER JOIN [MEDECINS] AS [t2] ON [t2].[ID] = [t1].[MEDECIN_ID]

WHERE ([t2].[NOM] = @p0) AND ([t0].[JOUR] = @p1)

// liste des clients ayant pris Rdv avec Mme Pélissier le 08/10/2012

Résultats  :

from rv in RVS where (rv.JOUR==new DateTime(2012,10,08) && rv.CRENEAU.MEDECIN.NOM=="Pelissier") select rv.CLIENT

-- Region Parameters

DECLARE @p0 DateTime = '2012-10-08 00:00:00.000'

DECLARE @p1 NVarChar(1000) = 'Pelissier'

-- EndRegion

SELECT [t3].[ID], [t3].[TITRE], [t3].[NOM], [t3].[PRENOM], [t3].[TIMESTAMP]

FROM [RVS] AS [t0]

INNER JOIN [CRENEAUX] AS [t1] ON [t1].[ID] = [t0].[CRENEAU_ID]

INNER JOIN [MEDECINS] AS [t2] ON [t2].[ID] = [t1].[MEDECIN_ID]

INNER JOIN [CLIENTS] AS [t3] ON [t3].[ID] = [t0].[CLIENT_ID]

WHERE ([t0].[JOUR] = @p0) AND ([t2].[NOM] = @p1)

Lambda

// nombre de créneaux horaires par médecin

Résultats  :

from creneau in CRENEAUXes 

group creneau by creneau.MEDECIN into creneauxMedecin 

select new { nom=creneauxMedecin.Key.NOM, prenom=creneauxMedecin.Key.PRENOM, nbRv=creneauxMedecin.Count()}

SELECT [t2].[NOM] AS [nom], [t2].[PRENOM] AS [prenom], [t1].[value] AS [nbRv]

FROM (

    SELECT COUNT(*) AS [value], [t0].[MEDECIN_ID]

    FROM [CRENEAUX] AS [t0]

    GROUP BY [t0].[MEDECIN_ID]

    ) AS [t1]

INNER JOIN [MEDECINS] AS [t2] ON [t2].[ID] = [t1].[MEDECIN_ID]

Lambda

Nous avons vu les opérations suivantes sur le contexte de persistance :

• ajouter un élément au contexte ( [dbContext].[DbSet].Add ) ;
• supprimer un élément du contexte ( [dbContext].[DbSet].Remove ) ;
• requêter un contexte avec des requêtes LINQ .

Lorsqu'on veut synchroniser le contexte avec la base, on écrit [dbContext].SaveChanges() .

Le code [ModifyAttachedEntity] illustre la modification d'une entité attachée au contexte :

using System;
using System.Data;
using System.Linq;
using RdvMedecins.Entites;
using RdvMedecins.Models;

namespace RdvMedecins_01
{
  class ModifyAttachedEntity
  {
    static void Main(string[] args)
    {
      Client client1, client2, client3;
      // 1er contexte
      using (var context = new RdvMedecinsContext())
      {
        // on vide la base actuelle
        foreach (var client in context.Clients)
        {
          context.Clients.Remove(client);
        }
        foreach (var medecin in context.Medecins)
        {
          context.Medecins.Remove(medecin);
        }
        // on ajoute un client
        client1 = new Client { Nom = "xx", Prenom = "xx", Titre = "xx" };
        context.Clients.Add(client1);
        // suivi
        Console.WriteLine("client1--avant");
        Console.WriteLine(client1);
        // sauvegarde contexte
        context.SaveChanges();
        // suivi
        Console.WriteLine("client1--après");
        Console.WriteLine(client1);
      }
      // 2ième contexte
      using (var context = new RdvMedecinsContext())
      {
        // on récupère client1 dans client2
        client2 = context.Clients.Find(client1.Id);
        // suivi
        Console.WriteLine("client2");
        Console.WriteLine(client2);
        // on modifie client2
        client2.Nom = "yy";
        // sauvegarde contexte
        context.SaveChanges();
      }
      // 3ième contexte
      using (var context = new RdvMedecinsContext())
      {
        // on récupère client2 dans client3
        client3 = context.Clients.Find(client2.Id);
        // suivi
        Console.WriteLine("client3");
        Console.WriteLine(client3);
      }
    }
  }
}

• ligne 15 : ouverture contexte de l'application ;
• lignes 18-25 : le contexte est vidé. Très exactement, toutes les entités sont amenées dans le contexte à partir de la base de données puis passent dans un état " supprimé ". On notera qu'à ce stade la base n'a pas bougé. Tant que le contexte n'est pas synchronisé avec la base, celle-ci ne change pas. On se rappelle que supprimer les entités [Medecin] et [Client] suffit à vider la base par le jeu des suppressions en cascade ;
• lignes 27-28 : un nouveau client est ajouté à la base ;
• lignes 30-31 : on l'affiche avant sa sauvegarde dans la base ;
• ligne 33 : on synchronise le contexte avec la base. Les entitées marquées dans un état " supprimé " vont faire l'objet d'une opération SQL DELETE, l'entité ajoutée d'une opération SQL INSERT ;
• lignes 35-36 : on affiche le client après la synchronisation avec la base ;

Le résultat obtenu à la console est le suivant :

client1--avant
Client[,xx,xx,xx,]
client1--après
Client[16,xx,xx,xx,000000132209]

On notera les points suivants :

• avant la synchronisation avec la base, le client n'a ni clé primaire, ni timestamp,
• après la synchronisation, il les a. On rappelle ici, que la clé primaire a été configurée pour être générée par SQL Server. De même ce SGBD génère automatiquement le timestamp ;
• ligne 37 : le contexte de persistance est fermé. Les entités qu'il contenait deviennent "  détachées  ". Elles existent en tant qu'objets mais pas en tant qu'entités attachées à un contexte de persistance ;
• ligne 39 : on redémarre un nouveau contexte vide ;
• ligne 42 : on récupère le client directement dans la base via sa clé primaire. Il est alors amené dans le contexte. S'il n'est pas trouvé, la méthode Find rend le pointeur null  ;
• lignes 48-49 : on l'affiche ;

Cela donne le résultat suivant :

client2
Client[16,xx,xx,xx,000000132209]

• ligne 47 : on le modifie ;
• ligne 49 : on synchronise le contexte avec la base. EF va détecter que certains éléments du contexte ont été modifiés depuis qu'ils y ont été amenés. Pour ces éléments, il va générer des ordres SQL UPDATE sur la base. Donc ici, la synchronisation va consister en un unique ordre UPDATE ;
• ligne 50 : le deuxième contexte est fermé. L'entité client2 qui était attachée au contexte devient maintenant détachée de celui-ci ;
• ligne 52 : on ouvre un troisième contexte vide ;
• ligne 55 : on y amène de nouveau l'unique client de la base. On veut voir si la modification faite sur lui dans le contexte précédent a été répercutée dans la base ;
• lignes 57-58 : on affiche le client. Cela donne le résultat suivant :

client3
Client[16,xx,xx,yy,000000132210]

Le nom du client a bien été modifié en base. On notera avec intérêt que son timestamp a été mis à jour.

• ligne 59 : on ferme le contexte. Au passage, on notera que contrairement aux deux fois précédentes, on n'a pas eu besoin auparavant de synchroniser le contexte avec la base (SaveChanges) car le contexte n'avait pas été modifié.

Revenons à l'architecture en couches d'une application telle que celle de l'étude de cas :

La couche [DAO] utilise l'ORM EF5 pour accéder aux données. Nous avons les briques de base de cette couche. Chaque méthode ouvrira un contexte de persistance, fera dessus les opérations nécessaires (insertion, modification, suppression, requêtage) puis le fermera. Les entités gérées par la couche [DAO] vont remonter jusqu'à la couche web ASP.NET. Dans cette couche, elles sont hors contexte de persistance donc détachées. Dans la couche web, un utilisateur peut modifier ces entités (ajout, modification, suppression). Lorsqu'elles reviennent à la couche [DAO], elles sont toujours détachées. Or la couche [DAO] va devoir répercuter les modifications faites par l'utilisateur dans la base. Il va donc devoir travailler avec des entités détachées. Voyons les trois cas possibles :

Ajouter une entité détachée

C'est le cas normal pour un ajout. Il suffit d'ajouter (Add) l'entité détachée au contexte en s'assurant qu'elle a une clé primaire égale à null .

Modifier une entité détachée

On peut utiliser le code suivant :

[DbContext].Entry(entité-détachée).State=EntityState.Modified ;

• la méthode [DbContext].Entry(entité-détachée) va mettre l'entité dans le contexte ;
• l'état de cette entité est mis à " modifié " afin qu'elle fasse l'objet d'un ordre SQL UPDATE.

Supprimer une entité détachée

On peut utiliser le code suivant :

Entity e=[DbContext].[DbSet].Find(clé primaire de l'entité détachée) ;
[DbContext].[DbSet].Remove(e) ;

• ligne 1 : on met dans le contexte l'entité de même clé primaire que l'entité détachée ;
• ligne 2 : on la supprime :

On notera que cela nécessite en base un SELECT suivi d'un DELETE alors que normalement le seul DELETE est suffisant. On peut suivre également l'exemple de la modification d'une entité détachée et écrire :

[DbContext].Entry(entité-détachée).State=EntityState.Deleted ;

Comme je n'ai pas pu mettre en œuvre de logs sur les opérations SQL faites sur la base, je ne sais pas si une méthode est à conseiller plutôt que l'autre.

Voici un exemple :

Le code du programme [ModifyDetachedEntities] est le suivant :

using System;
using System.Data;
using RdvMedecins.Entites;
using RdvMedecins.Models;

namespace RdvMedecins_01
{
  class ModifyDetachedEntities
  {
    static void Main(string[] args)
    {
      Client client1;

      // on vide la base actuelle
      Erase();
      // on ajoute un client
      using (var context = new RdvMedecinsContext())
      {
        // création client
        client1 = new Client { Titre = "x", Nom = "x", Prenom = "x" };
        // ajout du client au contexte
        context.Clients.Add(client1);
        // on sauvegarde le contexte
        context.SaveChanges();
      }
      // affichage base
      Dump("1-----------------------------");
      // client1 n'est pas dans le contexte - on le modifie
      client1.Nom = "y";
      // nouveau contexte
      using (var context = new RdvMedecinsContext())
      {
        // ici, on a un contexte vide
        // on met client1 dans le contexte dans un état modifié
        context.Entry(client1).State = EntityState.Modified;
        // on sauvegarde le contexte
        context.SaveChanges();
      }
      // affichage base
      Dump("2-----------------------------");
      // suppression entité hors contexte
      using (var context = new RdvMedecinsContext())
      {
        // ici, on a un nouveau contexte vide
        // on met client1 dans le contexte dans un état supprimé
        context.Entry(client1).State = EntityState.Deleted;
        // on sauvegarde le contexte
        context.SaveChanges();
      }
      // affichage base
      Dump("3-----------------------------");
    }

    static void Erase()
    {
      // vide la base
      using (var context = new RdvMedecinsContext())
      {
        foreach (var client in context.Clients)
        {
          context.Clients.Remove(client);
        }
        foreach (var medecin in context.Medecins)
        {
          context.Medecins.Remove(medecin);
        }
        // on sauvegarde le contexte
        context.SaveChanges();
      }
    }

    static void Dump(string str)
    {
      Console.WriteLine(str);
      // affiche la base
      using (var context = new RdvMedecinsContext())
      {
        foreach (var rv in context.Rvs)
        {
          Console.WriteLine(rv);
        }
        foreach (var creneau in context.Creneaux)
        {
          Console.WriteLine(creneau);
        }
        foreach (var client in context.Clients)
        {
          Console.WriteLine(client);
        }
        foreach (var medecin in context.Medecins)
        {
          Console.WriteLine(medecin);
        }
      }
    }
  }
}

• ligne 15 : la base est effacée ;
• lignes 17-25 : un client est ajouté en base ;
• ligne 27 : affiche le contenu de la base ;

1-----------------------------

Client[20,x,x,x,0000011209]

• après la ligne 25, le contexte de persistance n'existe plus. Il n'y a donc plus d'entités attachées. L'entité client1 est passée dans l'état "  détaché  " ;
• ligne 29 : on modifie le nom de l'entité détachée ;
• ligne 31 : on ouvre un nouveau contexte vide ;
• ligne 35 : l'entité détachée client1 est mise dans le contexte dans un état "  modifié  " ;
• ligne 37 : le contexte est synchronisé avec la base ;
• ligne 38 : il est fermé ;
• ligne 40 : la base est affichée ;

2-----------------------------

Client[20,x,x,y,0000011210]

Le nom du client a bien été modifié en base. On notera que le timestamp a été mis à jour ;

• ligne 42 : ouverture d'un nouveau contexte vide ;
• ligne 46 : l'entité détachée client1 est mise dans le contexte dans un état " supprimé " ;
• ligne 48 : le contexte est synchronisé avec la base ;
• ligne 49 : il est fermé ;
• ligne 51 : la base est affichée ;

3-----------------------------

L'entité a bien été supprimée en base.

Maintenant, nous voyons les deux modes de chargement des dépendances d'une entité : Lazy et Eager Loading .

Reprenons le schéma des dépendances plusieurs à un de nos quatre entités :

Ci-dessus, l'entité [Creneau] a une propriété navigationnelle [Creneau.Medecin] vers l'entité [Medecin]. On appelle cela une dépendance. Nous avons vu qu'il y avait également des dépendances un à plusieurs . Le principe qui va être expliqué s'applique également à elles.

Par défaut, EF 5 est en mode Lazy Loading  : lorsqu'il amène une entité dans le contexte de persistance depuis la base, il n'amène pas ses dépendances. Celles-ci seront amenées lorsqu'elles seront utilisées la première fois. C'est une mesure de bon sens. Si ce n'était pas le cas, amener dans le contexte les rendez-vous amènerait d'après les dépendances ci-dessus :

• les entités [Creneau] liées aux rendez-vous ;
• les entités [Medecin] liées à ces créneaux ;
• les entités [Clients] liées aux rendez-vous.

Parfois cependant, on a besoin d'une entité et de ses dépendances. Nous allons illustrer les deux modes de chargement.

Le code de [LazyEagerLoading] est le suivant :

using RdvMedecins.Entites;
using RdvMedecins.Models;
using System;
using System.Linq;

namespace RdvMedecins_01
{
  class LazyEagerLoading
  {
    // les entités
    static Medecin[] medecins;
    static Client[] clients;
    static Creneau[] creneaux;

    static void Main(string[] args)
    {
      // on initialise la base      
      InitBase();
      Console.WriteLine("Initialisation terminée");
      // eager loading
      Creneau creneau;
      int idCreneau = (int)creneaux[0].Id;
      using (var context = new RdvMedecinsContext())
      {
        // creneau n° 0
        creneau = context.Creneaux.Include("Medecin").Single<Creneau>(c => c.Id == idCreneau);
        Console.WriteLine(creneau.ShortIdentity());
      }
      // affichage dépendance
      try
      {
        Console.WriteLine("Médecin={0}", creneau.Medecin);
      }
      catch (Exception e)
      {
        Console.WriteLine("L'erreur 1 suivante s'est produite : {0}", e);
      }
      // lazy loading - mode par défaut
      using (var context = new RdvMedecinsContext())
      {
        // creneau n° 0
        creneau = context.Creneaux.Single<Creneau>(c => c.Id == idCreneau);
        Console.WriteLine(creneau.ShortIdentity());
      }
      // affichage dépendance
      try
      {
        Console.WriteLine("Médecin={0}", creneau.Medecin);
      }
      catch (Exception e)
      {
        Console.WriteLine("L'erreur 2 suivante s'est produite : {0}", e);
      }

    }

    static void InitBase()
    {
      // on initialise la base
      using (var context = new RdvMedecinsContext())
      {
        // on vide la base actuelle
        ...
        // on initialise la base
        // les clients
        clients = new Client[] {
        new Client { Titre = "Mr", Nom = "Martin", Prenom = "Jules" },
        new Client { Titre = "Mme", Nom = "German", Prenom = "Christine" },
        new Client { Titre = "Mr", Nom = "Jacquard", Prenom = "Jules" },
        new Client { Titre = "Melle", Nom = "Bistrou", Prenom = "Brigitte" }
     };
...
        // les Rdv
        context.Rvs.Add(new Rv { Jour = new System.DateTime(2012, 10, 8), Client = clients[0], Creneau = creneaux[0] });
        // on sauve le contexte de persistance
        context.SaveChanges();
      }
    }
  }
}

• ligne 18 : on part d'une base connue, celle utilisée jusqu'à maintenant. Après cette opération, les tableaux des lignes 11-13 sont remplis d'entités détachées ;
• lignes 21-22 : on s'intéresse au premier créneau et au médecin associé ;
• ligne 23 : nouveau contexte ;
• ligne 26 : on met le créneau dans le contexte avec sa dépendance (eager loading). Parce que ce n'est pas le mode par défaut, il faut demander explicitement cette dépendance. C'est la méthode Include qui permet cela. Son paramètre est le nom de la dépendance dans l'entité amenée dans le contexte. La requête qui amène l'entité dans le contexte utilise des expressions lambda. La méthode Single permet de préciser une condition permettant de ramener une unique entité. Ici, on recherche en base l'entité [Creneau] qui a la clé primaire du créneau n° 0 ;
• ligne 27 : on affiche l'entité ramenée. Rappelons les deux méthodes d'écriture utilisées dans les entités :

// signature
    public override string ToString()
    {
      return String.Format("Creneau[{0},{1},{2},{3},{4}, {5},{6}]", Id, Hdebut, Mdebut, Hfin, Mfin, Medecin, dump(Timestamp));
    }
 
   // signature courte
    public string ShortIdentity()
    {
      return String.Format("Creneau[{0},{1},{2},{3},{4}, {5}, {6}]", Id, Hdebut, Mdebut, Hfin, Mfin, MedecinId, dump(Timestamp));
    }

• lignes 2-5 : la méthode [ToString] affiche la dépendance [Medecin]. Si celle-ci n'est pas déjà dans le contexte, elle sera cherchée en base pour l'y mettre ;
• lignes 8-11 : la méthode [ShortIdentity] n'affiche pas la dépendance [Medecin]. Elle ne sera donc pas recherchée en base si elle n'est pas dans le contexte ;

A ce stade, l'affichage console est le suivant :

Initialisation terminée

Creneau[181,8,0,8,20, 21, 00000195150]

• ligne 28 : le contexte est fermé ;
• lignes 30-37 : on essaie d'écrire la dépendance [Medecin] de l'entité. On rappelle le fonctionnement en Lazy Loading  : une dépendance est chargée lors de sa première utilisation si elle n'est pas présente. Ici, normalement elle est présente. L'affichage est le suivant :

Médecin=Medecin[21,Mme,Marie,Pelissier,00000195149]

• lignes 39-44 : dans le cadre d'un nouveau contexte, le créneau n° 0 est de nouveau cherché en base et amené dans le contexte. Ici, la dépendance [Medecin] n'est pas demandée explicitement. Elle ne sera donc pas amenée (Lazy Loading) ;
• ligne 43 : l'affichage de l'identité courte du créneau est la suivante :

Creneau[181,8,0,8,20, 21, 00000195150]

Ici, il est important d'utiliser ShortIdentity au lieu de ToString pour afficher l'entité. Si on utilise ToString , la dépendance [Medecin] va être affichée et pour cela elle va être cherchée en base. Or on ne veut pas cela.

• ligne 44 : le contexte est fermé ;
• lignes 46-53 : on essaie d'afficher la dépendance de l'entité. Il est important de faire cela hors contexte sinon elle sera recherchée en base et trouvée. Ici on est hors contexte. L'entité [Creneau] est détachée et sa dépendance [Medecin] est absente (Lazy Loading). Que va-t-il se passer ? L'affichage écran est le suivant :

L'erreur 2 suivante s'est produite : System.ObjectDisposedException: L'instance ObjectContext a été supprimée et ne peut plus être utilisée pour les opérations qui requièrent une connexion.
   à System.Data.Objects.ObjectContext.EnsureConnection()
   à System.Data.Objects.ObjectQuery`1.GetResults(Nullable`1 forMergeOption)
   à System.Data.Objects.ObjectQuery`1.Execute(MergeOption mergeOption)
   à System.Data.Objects.DataClasses.EntityReference`1.Load(MergeOption mergeOption)
   à System.Data.Objects.DataClasses.RelatedEnd.Load()
   à System.Data.Objects.DataClasses.RelatedEnd.DeferredLoad()
   à System.Data.Objects.Internal.LazyLoadBehavior.LoadProperty[TItem](TItem propertyValue, String relationshipName, String targetRoleName, Boolean mustBeNull,Object wrapperObject)
   à System.Data.Objects.Internal.LazyLoadBehavior.<>c__DisplayClass7`2.<GetInterceptorDelegate>b__2(TProxy proxy, TItem item)
   à System.Data.Entity.DynamicProxies.Creneau_AF14A89855AD9B7E5ABA4A877B4989B2F8B3F7ECA154E3FEC02BA722002773E4.get_Medecin()
   à RdvMedecins_01.LazyEagerLoading.Main(String[] args) dans d:\data\istia-1213\c#\dvp\Entity Framework\RdvMedecins\RdvMedecins-SqlServer-01\LazyEagerLoading.cs:ligne 48

EF a trouvé la dépendance [Medecin] absente. Il a voulu la charger mais le contexte étant fermé, cette opération n'était plus possible. On mémorisera cette exception [System.ObjectDisposedException] car est elle caractéristique du chargement d'une dépendance en-dehors d'un contexte ouvert.

Maintenant examinons la concurrence d'accès aux entités.

Revenons sur la définition de l'entité [Client] :

public class Client
  {
    // data
    [Key]
    [Column("ID")]
    public int? Id { get; set; }
    [Required]
    [MaxLength(5)]
    [Column("TITRE")]
    public string Titre { get; set; }
    [Required]
    [MaxLength(30)]
    [Column("NOM")]
    public string Nom { get; set; }
    [Required]
    [MaxLength(30)]
    [Column("PRENOM")]
    public string Prenom { get; set; }
    // les Rvs du client
    public ICollection<Rv> Rvs { get; set; }
    [Column("TIMESTAMP")]
    [Timestamp]
    public byte[] Timestamp { get; set; }

    // signature
    ...
  }

Nous allons nous intéresser au champ [Timestamp] de la ligne 23. Nous savons que sa valeur est générée par le SGBD. Nous avons dit également que l'annotation [Timestamp] de la ligne 22 faisait que EF 5 utilisait le champ annoté pour gérer les concurrences d'accès aux entités. Rappelons ce qu'est une gestion de concurrence d'accès :

• un processus P1 lit une ligne L de la table [MEDECINS] au temps T1. La ligne a le timestamp TS1 ;
• un processus P2 lit la même ligne L de la table [MEDECINS] au temps T2. La ligne a le timestamp TS1 parce que le processus P1 n'a pas encore validé sa modification ;
• le processus P1 valide sa modification de la ligne L. Le timestamp de la ligne L passe alors à TS2 ;
• le processus P2 valide sa modification de la ligne L. L'ORM lance alors une exception car le processus P2 a un timestamp TS1 de la ligne L différent du timestamp TS2 trouvé en base.

On appelle cela la gestion optimiste des accès concurrents. Avec EF 5, un champ jouant ce rôle doit avoir l'un des deux attributs [Timestamp] ou [ConcurrencyCheck]. SQL server a un type [timestamp]. Une colonne ayant ce type voit sa valeur automatiquement générée par SQL Server à toute insertion / modification d'une ligne. Une telle colonne peut alors servir à gérer la concurrence d'accès.

Nous allons illustrer cette concurrence d'accès avec deux threads qui vont modifier en même temps une même entité [Client] en base. Le projet évolue comme suit :

Le code du programme [AccèsConcurrents] est le suivant :

using System;
using System.Data;
using System.Linq;
using System.Threading;
using RdvMedecins.Entites;
using RdvMedecins.Models;

namespace RdvMedecins_01
{

  // objet échangé avec les threads
  class Data
  {
    public int Duree { get; set; }
    public string Nom { get; set; }
    public Client Client { get; set; }
  }

  // programme de test
  class AccèsConcurrents
  {

    static void Main(string[] args)
    {
      Client client1;
      using (var context = new RdvMedecinsContext())
      {
        // thread principal
        Thread.CurrentThread.Name = "main";
        // on vide la base actuelle
        foreach (var client in context.Clients)
        {
          context.Clients.Remove(client);
        }
        foreach (var medecin in context.Medecins)
        {
          context.Medecins.Remove(medecin);
        }
        // on ajoute un client
        client1 = new Client { Nom = "xx", Prenom = "xx", Titre = "xx" };
        context.Clients.Add(client1);
        // suivi
        Console.WriteLine("{0} client1--avant sauvegarde du contexte", Thread.CurrentThread.Name);
        Console.WriteLine(client1.ShortIdentity());
        // sauvegarde
        context.SaveChanges();
        // suivi
        Console.WriteLine("{0} client1--après sauvegarde du contexte", Thread.CurrentThread.Name);
        Console.WriteLine(client1.ShortIdentity());
      }
      // on va modifier client1 avec deux threads
      // thead t1
      Thread t1 = new Thread(Modifie);
      t1.Name = "t1";
      t1.Start(new Data { Duree = 5000, Nom = "yy", Client = client1 });
      // thread t2
      Thread t2 = new Thread(Modifie);
      t2.Name = "t2";
      t2.Start(new Data { Duree = 5000, Nom = "zz", Client = client1 });
      // on attend la fin des 2 threads
      Console.WriteLine("Thread {0} -- début attente fin des deux threads", Thread.CurrentThread.Name);
      t1.Join();
      t2.Join();
      Console.WriteLine("Thread {0} -- fin attente fin des deux threads", Thread.CurrentThread.Name);
      // on affiche la modification - une seule a du réussir
      using (var context = new RdvMedecinsContext())
      {
        // on récupère client1 dans client2
        Client client2 = context.Clients.Find(client1.Id);
        Console.WriteLine("Thread {0} client2", Thread.CurrentThread.Name);
        Console.WriteLine("Thread {0} {1}", Thread.CurrentThread.Name, client2.ShortIdentity());
      }
    }

    // thread
    static void Modifie(object infos)
    {
 ...
}