blog.pagesd.info

Après avoir fait quelques essais très basiques avec NHibernate, j'ai voulu essayer d'être plus concret et d'aller un peu plus loin en tentant de porter l'application Contact Manager sous NHibernate. A priori, ça ne devait pas être trop compliqué dans la mesure où il y a quelques temps j'avais déjà remplacé Entity Framework par LINQ to SQL et que ça ne s'était pas trop mal passé. Sans compter, que je souhaitais juste faire en sorte que ça marche à peu près tel quel, sans trop chercher à découvrir ou à mettre au point la "bonne" façon d'utiliser NHibernate avec ASP.NET MVC.

Dans la pratique, ça m'a pris un peu plus de temps que ce que j'avais pensé y consacrer. En fait, j'aurais pu faire ce billet depuis un petit moment, mais avant il fallait que j'arrive à mettre au propre la solution que j'avais suivie. Parce que c'est là que le bât blesse, c'est qu'avec NHibernate il y a tout plein de façons de faire et que je n'ai pas réussi à trouver une documentation "officielle" (et récente) qui décrive clairement quel est l'état de l'art pour utiliser NHibernate dans le cadre d'une application ASP.NET.

Voici donc parmi tous mes essais (avec des réussites, des ratés et des abandons) une des façons de faire à laquelle je suis arrivé et qui est assez "simple" à expliquer. Ca marche correctement, mais je ne peux absolument pas affirmer que c'est la méthode à suivre.

Etape 1 : Installer NHibernate

Pour faire simple, le plus pratique est d'aller sur le site de Castle ActiveRecord et d'y télécharger la toute dernière version d'Active Record. Une fois l'archive décompressée, il suffit de créer un répertoire "lib" dans le répertoire racine de "ContactManager" et d'y copier les quelques fichiers suivants :

• Iesi.Collections.dll
• Iesi.Collections.xml
• LinFu.DynamicProxy.dll
• log4net.dll
• log4net.xml
• nhibernate-configuration.xsd
• nhibernate-mapping.xsd
• NHibernate.ByteCode.LinFu.dll
• NHibernate.ByteCode.LinFu.xml
• NHibernate.dll
• NHibernate.Linq.dll
• NHibernate.xml

En réalité, je n'utilise pas du tout l'approche Active Record. Mais l'avantage de passer par leur site c'est qu'on est certain d'avoir DLLs récentes avec des versions compatibles entre elles. Au cours de mes différents essais, j'avais récupéré des DLLs au fur et à mesure de mes besoins et d'un petit peu tous les côtés et ça m'avait joué quelques mauvais tours.

Une fois ces différentes librairies mises en place, il suffit de référencer les 4 éléments suivants dans l'application ContactManager existante :

• log4net.dll
• NHibernate.dll
• NHibernate.ByteCode.LinFu.dll
• NHibernate.Linq.dll

Et pour bien faire les choses, il faut aussi prendre le temps de dé-référencer les éléments qui correspondent à Entity Framework et par conséquent de supprimer les fichiers liés à EF dans le sous-répertoire Models.

Etape 2 : Configurer NHibernate

NHibernate est installé et référencé au niveau du projet. Il faut maintenant le configurer pour lui expliquer qu'on aimerait bien qu'il utilise notre base de données SQL Server habituelle. Et là commence la galère puisqu'il existe apparement des tonnes de façon différentes pour faire ça. J'en ai essayé quelques unes et je n'ai pas vraiment très bien compris quels sont les avantages et les inconvénients de telle ou telle façon de faire (mais c'est vrai que j'ai pas trop passé de temps dessus).

Par conséquent, je vais aller au plus simple et donner directement la méthode que j'ai repérée sur la vidéo de présentation de NHibernate proposée par TekPub. C'est juste un extrait, mais ça m'a suffi pour emprunter le source à l'application Kona de Rob Conery. Cela consiste à créer un fichier "nhibernate.config" à la racine de l'application ASP.NET MVC pour y définir tous les éléments nécessaires pour configurer NHibernate :

<?xml version="1.0" encoding="utf-8" ?>
<hibernate-configuration xmlns="urn:nhibernate-configuration-2.2">

  <session-factory name="ContactManager">
    <property name="dialect">NHibernate.Dialect.MsSql2008Dialect</property>
    <property name="connection.driver_class">NHibernate.Driver.SqlClientDriver</property>
    <property name="connection.connection_string">server=.\SQLExpress;database=ContactManagerDB;Integrated Security=true;</property>
    <property name="show_sql">true</property>
    <property name="cache.use_query_cache">false</property>
    <property name="adonet.batch_size">16</property>
    <property name="proxyfactory.factory_class">NHibernate.ByteCode.LinFu.ProxyFactoryFactory, NHibernate.ByteCode.LinFu</property>
    <mapping assembly="ContactManager" />
  </session-factory>
  
</hibernate-configuration>

Par rapport à l'écriture de ces informations dans le Web.config, il me semble que c'est un peu plus clair d'isoler ça dans un fichier à part (sans compter que ça évite de complexitrifier le fichier Web.config inutilement). Sinon, il aurait aussi été possible d'utiliser directement le fichier "hibernate.cfg.xml" standard mais je trouve qu'un fichier ".config" c'est plus propre (et plus sûr ?) qu'un fichier ".xml".

Etape 3 : Gérer une session NHibernate

Dans la version Entity Framework de l'application Contact Manager, on utilise un objet ContactManagerDBEntities généré automatiquement par ADO.NET EF pour communiquer avec la base de données SQL Server. Dans la version portée sous LINQ to SQL, c'est un objet ContactManagerModelDataContext qui joue ce rôle.

En ce qui concerne NHibernate, les communications avec la base de données se font par l'intermédiaire d'un objet Session. Et là aussi, pour gérer / instancier cet objet Session, il existe tout plein de façons de faire.

Pour l'instant, je reprend de façon ultra simplifiée la méthode proposée par Rob Conery parce qu'il est possible de la mettre en oeuvre en très très peu de lignes au niveau du fichier global.asax.cs :

using System;
using System.IO;
using System.Web.Mvc;
using System.Web.Routing;
using NHibernate;
using NHibernate.Cfg;

namespace ContactManager
{

    public class MvcApplication : System.Web.HttpApplication
    {

        public static ISessionFactory SessionFactory = CreateSessionFactory();

        private static ISessionFactory CreateSessionFactory()
        {
            var cfg = new Configuration().Configure(Path.Combine(AppDomain.CurrentDomain.BaseDirectory, "nhibernate.config"));
            return cfg.BuildSessionFactory();
        }

Grâce à ça, il devient tout simple de remplacer la ligne :

private ContactManagerDBEntities _entities = new ContactManagerDBEntities();

par l'instruction suivante :

private ISession _session = MvcApplication.SessionFactory.GetCurrentSession();

Etape 4 : Faire le mapping entre les tables et les objets

Avec NHibernate, les classes Contact et Group ne sont pas générées automatiquement comme avec Entity Framework ou LINQ to SQL. Il faut donc créer à la main des classes POCO (c'est pas le plus compliqué) et il faut également créer un fichier de mapping XML pour associer chaque classe à la table correspondante dans la base de données (c'est déjà un peu plus mariole).

Je ne vais pas expliquer comment faire ni entrer dans les détails de comment ça marche (en plus je n'ai pas encore suffisament bien compris moi-même), mais voici ce à quoi je suis arrivé après quelques essais.

Models\Contact.cs

namespace ContactManager.Models
{
    public partial class Contact
    {
        public Contact()
        {
            Group = new Group();
        }
        public virtual int Id { get; set; }
        public virtual string FirstName { get; set; }
        public virtual string LastName { get; set; }
        public virtual string Phone { get; set; }
        public virtual string Email { get; set; }
        public virtual Group Group { get; set; }

        /// <summary>
        /// Create a new Contact object.
        /// </summary>
        /// <param name="id">Initial value of Id.</param>
        /// <param name="firstName">Initial value of FirstName.</param>
        /// <param name="lastName">Initial value of LastName.</param>
        /// <param name="phone">Initial value of Phone.</param>
        /// <param name="email">Initial value of Email.</param>
        public static Contact CreateContact(int id, string firstName, string lastName, string phone, string email)
        {
            Contact contact = new Contact();
            contact.Id = id;
            contact.FirstName = firstName;
            contact.LastName = lastName;
            contact.Phone = phone;
            contact.Email = email;
            return contact;
        }
    }

}

Mappings\Contact.hbm.xml

<?xml version="1.0" encoding="utf-8" ?>
<hibernate-mapping xmlns="urn:nhibernate-mapping-2.2" namespace="ContactManager.Models" assembly="ContactManager">

  <class name="Contact" table="Contacts" dynamic-update="true">

    <cache usage="read-write" />

    <id name="Id" column="Id" type="integer">
      <generator class="identity" />
    </id>
    <property name="FirstName" type="string" />
    <property name="LastName" type="string" />
    <property name="Phone" type="string" />
    <property name="Email" type="string" />
    <many-to-one name="Group" column="groupId" not-null="true" />

  </class>

</hibernate-mapping>

Models\Group.cs

using System.Collections.Generic;

namespace ContactManager.Models
{
    public class Group
    {
        public Group()
        {
            Contacts = new List<Contact>();
        }
        public virtual int Id { get; set; }
        public virtual string Name { get; set; }
        public virtual IList<Contact> Contacts { get; set; }
    }
}

Mappings\Group.hbm.xml

<?xml version="1.0" encoding="utf-8" ?>
<hibernate-mapping xmlns="urn:nhibernate-mapping-2.2" namespace="ContactManager.Models" assembly="ContactManager">

  <class name="Group" table="Groups" dynamic-update="true">

    <cache usage="read-write" />

    <id name="Id" column="Id" type="integer">
      <generator class="identity" />
    </id>
    <property name="Name" type="string" />
    <bag
        name="Contacts"
        inverse="true"
        lazy="true">
      <key column="groupId" />
      <one-to-many class="Contact" />
    </bag>

  </class>

</hibernate-mapping>

En ce qui concerne les deux fichiers Contact.hbm.xml et Group.hbm.xml, il faut impérativement modifier leur propriété "Action de génération" au niveau de l'explorateur de projet pour la définir à "Ressource incorporée" sans quoi le mapping NHibernate ne fonctionne pas. C'est un problème très facile à identifier parce qu'on obtient une erreur "Association references unmapped class: ContactManager.Models.Contact" dès le lancement de l'application.

Redévelopper le repository avec NHibernate

Après ces 4 premières étapes, tout est enfin prêt pour pouvoir modifier la couche repository de l'application afin de remplacer Entity Framework par NHibernate :

• NHibernate est installé et référencé
• NHibernate est configuré pour accéder à la base de données SQL Server
• Un objet NHibernate Session a été défini pour communiquer avec la base de données
• Les objets données et les fichiers de mapping NHibernate sont en place

Par conséquent, il ne reste plus qu'à implémenter l'interface IContactManagerRepository en utilisant NHibernate et LINQ to NHibernate pour remplacer le fichier EntityContactManagerRepository.cs qui l'implémentait pour Entity Framework.

Models\NHContactManagerRepository.cs

using System.Collections.Generic;
using System.Linq;
using NHibernate;
using NHibernate.Linq;

namespace ContactManager.Models
{
    public class NHContactManagerRepository : IContactManagerRepository
    {
        private ISession _session = ContactManager.MvcApplication.SessionFactory.OpenSession();

        public Contact GetContact(int id)
        {
            return (from c in _session.Linq<Contact>()
                    where c.Id == id
                    select c).FirstOrDefault();
        }

        public Contact CreateContact(int groupId, Contact contactToCreate)
        {
            // Associate group with contact
            contactToCreate.Group = GetGroup(groupId);

            // Save new contact
            _session.SaveOrUpdate(contactToCreate);
            return contactToCreate;
        }

        public Contact EditContact(int groupId, Contact contactToEdit)
        {
            // Associate with new group
            contactToEdit.Group = GetGroup(groupId);

            // Save changes
            _session.SaveOrUpdate(contactToEdit);
            _session.Flush();
            return contactToEdit;
        }

        public void DeleteContact(Contact contactToDelete)
        {
            _session.Delete(contactToDelete);
            _session.Flush();
        }

        public Group CreateGroup(Group groupToCreate)
        {
            _session.SaveOrUpdate(groupToCreate);
            return groupToCreate;
        }

        public IEnumerable<Group> ListGroups()
        {
            return _session.Linq<Group>().OrderBy(o => o.Name).ToList();
        }

        public Group GetFirstGroup()
        {
            return _session.Linq<Group>().FirstOrDefault();
        }

        public Group GetGroup(int id)
        {
            return (from g in _session.Linq<Group>()
                    where g.Id == id
                    select g).FirstOrDefault();
        }

        public void DeleteGroup(Group groupToDelete)
        {
            _session.Delete(groupToDelete);
            _session.Flush();
        }

    }
}

Une fois encore, je n'ai pas cherché à faire "bien" mais simplement à ce que ça marche. Dans la pratique, il vaudrait mieux éviter tous ces "_session.Flush()" et passer par des transactions et des "using" mais pour l'instant, ce n'était absolument pas mon objectif.

Pour pouvoir compiler et vérifier que tout fonctionne comme prévu, il reste encore à modifier le constructeur ContactManagerService pour qu'il utilise ce repository en lieu et place de celui d'Entity Framework.

public ContactManagerService(IValidationDictionary validationDictionary)
    : this(validationDictionary, new NHContactManagerRepository())
{
}

Une fois cette ultime modification réalisée, la solution compile sans aucune erreur et elle m'offre bien les mêmes fonctionnalités que les versions avec Entity Framework ou LINQ to SQL :

• lister les contacts rattachés à un groupe,
• ajouter, modifier ou supprimer un contact,
• ajouter ou supprimer un groupe de contacts.

Et juste pour le plaisir, je peux lancer les quelques tests unitaires de ContactManager.Test et tout va bien !

Conclusion

Par rapport au passage sous LINQ to SQL, ça a été beaucoup plus laborieux. Le problème, c'est qu'il y a à la fois beaucoup (trop) de façon de faire et beaucoup (trop) d'informations disponibles ce qui fait qu'il n'est vraiment pas évident de savoir dans quelle direction partir.

Mais malgré tout, c'est quand même un succès. Il a suffi de changer le repository (et de recréer les classes Contact et Group générées automatiquement) pour que l'application ContactManager de base fonctionne correctement avec NHibernate. C'est donc un nouveau bon point pour le pattern Repository (zut! juste au moment où j'avais presque envie de me (ré)orienter vers Active Record). Et avec la prochaine version de Entity Framework qui devrait être POCO friendly, on peut même supposer que ce sera de plus en plus facile de passer d'un ORM à l'autre.

Peut-être que plus tard (c'est à dire une fois que je saurai faire), j'écrirai un autre billet pour présenter une façon d'utiliser Nibernate avec ASPNET MVC qui soit un peu plus orthodoxe. Mais déjà, j'aimerai très vite essayer de voir ce que ça donne en changeant la base de données et en testant cette version de Contactmanager NHibernate avec MySQL ou Oracle.

Encouragé par un premier succès pour faire passer le tutoriel ContactManager en tout jQuery, j'ai décidé de continuer ma formation ASP.NET MVC en modifiant l'application ContactManager pour remplacer Entity Framework par LINQ to SQL.

Création du modèle LINQ to SQL

Après un ou deux essais, j'ai vu que le plus pratique était de commencer par exclure ou supprimer du projet tout ce qui touchait à Entity Framework, à savoir ContactManagerModel.edmx et EntityContactManagerRepository.cs. Il devient alors possible d'ajouter un modèle LINQ to SQL au projet pour représenter la base de données, sans que cela provoque des définitions en double avec les objets générés par Entity Framework.

L'ajout d'un modèle LINQ to SQL est plutôt simple :

• se placer dans le dossier Models de l'explorateur de solution
• faire un clic droit pour sélectionner la commande "New items..."
• dans la catégorie "Data", choisir le modèle "LINQ to SQL Classes"
• le nommer "ContactManagerModel.dbml" et cliquer sur le bouton "Add" pour le créer

Le concepteur LINQ to SQL est alors automatiquement ouvert et il est possible d'y faire glisser les deux tables "Contacts" et "Groups" depuis l'explorateur de base de données, ce qui a pour effet de :

• créer les classes "Contact" et "Group" basées sur ces deux tables
• ajouter une propriété "Group" à la classe "Contact" pour refléter le côté "1" de la relation entre les deux tables
• ajouter une propriété "Contacts" à la classe "Group" pour refléter le côté "N" de la relation entre les deux tables

Cela génère aussi une classe ContactManagerModelDataContext.cs qui fourni deux propriétés "Contacts" et "Groups" permettant de gérer des objets "Contact" et "Group" issus de la base de données.

Concrètement, cette première étape a eu pour résultat de substituer ContactManagerModel.dbml à ContactManagerModel.edmx.

Création d'un Repository basé sur LINQ to SQL

Cette seconde étape va consister à remplacer EntityContactManagerRepository.cs par une classe L2SContactManagerRepository.cs qui implémente elle aussi l'interface IContactManagerRepository. Et au lieu d'utiliser un objet ContactManagerDBEntities, cette nouvelle classe va utiliser un objet ContactManagerModelDataContext.

using System.Collections.Generic;
using System.Linq;

namespace ContactManager.Models
{
    public class L2SContactManagerRepository : IContactManagerRepository
    {
        private ContactManagerModelDataContext _context = new ContactManagerModelDataContext();

        ...
    }
}

Il reste alors à implémenter les différentes méthodes déclarées dans l'interface IContactManagerRepository, mais à la sauce LINQ to SQL. Par rapport au repository basé sur Entity Framework, les différences sont finalement assez mineures.

• Les objets _entities.ContactSet et _entities.GroupSet deviennent des objets _context.Contacts et _context.Groups :

// ---------- Entity Framework
public IEnumerable<Group> ListGroups()
{
    return _entities.GroupSet.OrderBy(o => o.Name).ToList();
}

// ---------- LINQ to SQL
public IEnumerable<Group> ListGroups()
{
    return _context.Groups.OrderBy(o => o.Name).ToList();
}

• Les méthodes pour la mise à jour des données ont des noms différents : AddToXxxxxxSet() devient InsertOnSubmit(), DeleteObject() devient DeleteOnSubmit() et SaveChanges() devient SubmitChanges() :

// ---------- Entity Framework
public Group CreateGroup(Group groupToCreate)
{
    _entities.AddToGroupSet(groupToCreate);
    _entities.SaveChanges();
    return groupToCreate;
}

// ---------- LINQ to SQL
public Group CreateGroup(Group groupToCreate)
{
    _context.Groups.InsertOnSubmit(groupToCreate);
    _context.SubmitChanges();
    return groupToCreate;
}

• La méthode ApplyPropertyChanges() de Entity Framework n'ayant apparemment pas d'équivalent en LINQ to SQL, et le helper UpdateModel() étant lié à la classe Controller, je me suis pour l'instant contenté d'une mise à jour des propriétés à la main pour retrouver la même fonctionnalité :

// ---------- Entity Framework
public Contact EditContact(int groupId, Contact contactToEdit)
{
    // Get original contact
    var originalContact = GetContact(contactToEdit.Id);
    
    // Update with new group
    originalContact.Group = GetGroup(groupId);
    
    // Save changes
    _entities.ApplyPropertyChanges(originalContact.EntityKey.EntitySetName, contactToEdit);
    _entities.SaveChanges();
    return contactToEdit;
}

// ---------- LINQ to SQL
public Contact EditContact(int groupId, Contact contactToEdit)
{
    // Get original contact
    var originalContact = GetContact(contactToEdit.Id);

    // Update with new group
    originalContact.Group = GetGroup(groupId);

    // Update properties
    originalContact.FirstName = contactToEdit.FirstName;
    originalContact.LastName = contactToEdit.LastName;
    originalContact.Phone = contactToEdit.Phone;
    originalContact.Email = contactToEdit.Email;

    // Save changes
    _context.SubmitChanges();
    return contactToEdit;
}

Malgré tout, il y a une autre "grosse" différence dans la mesure où avec Entity Framework on utilise la méthode Include(relation) dans la requête LINQ pour retrouver les objets associés à l'élément sur lequel on effectue la requête.

Concrètement, cela a pour effet de générer une jointure lors de l'exécution de la requête LINQ.

• Sans le Include(relation) :

return (from c in _entities.ContactSet
        where c.Id == id
        select c).FirstOrDefault();

=>  SELECT 1 AS [C1], 
                [Extent1].[Id] AS [Id], 
                [Extent1].[FirstName] AS [FirstName], 
                [Extent1].[LastName] AS [LastName], 
                [Extent1].[Phone] AS [Phone], 
                [Extent1].[Email] AS [Email], 
                [Extent1].[groupId] AS [groupId]
        FROM [dbo].[Contacts] AS [Extent1]
        WHERE [Extent1].[Id] = @p__linq__1

• Avec le Include(relation) :

return (from c in _entities.ContactSet.Include("Group")
        where c.Id == id
        select c).FirstOrDefault();

=> SELECT 1 AS [C1], 
                [Extent1].[Id] AS [Id], 
                [Extent1].[FirstName] AS [FirstName], 
                [Extent1].[LastName] AS [LastName], 
                [Extent1].[Phone] AS [Phone], 
                [Extent1].[Email] AS [Email], 
                [Extent2].[Id] AS [Id1], 
                [Extent2].[Name] AS [Name]
        FROM  [dbo].[Contacts] AS [Extent1]
        LEFT OUTER JOIN [dbo].[Groups] AS [Extent2] ON [Extent1].[groupId] = [Extent2].[Id]
        WHERE [Extent1].[Id] = @p__linq__1

Là aussi, je n'ai pas réussi à trouver d'équivalent pour LINQ to SQL, d'autant que dans ce cas je n'ai pas cherché avec beaucoup d'acharnement puisque l'application fonctionne parfaitement même si on s'en passe...

// ---------- Entity Framework
public Contact GetContact(int id)
{
    return (from c in _entities.ContactSet.Include("Group")
            where c.Id == id
            select c).FirstOrDefault();
}

// ---------- LINQ to SQL
public Contact GetContact(int id)
{
    return (from c in _context.Contacts
            where c.Id == id
            select c).FirstOrDefault();
}

Isoler les tests unitaires de l'ORM

Une fois la classe Repository complètement ré-écrite pour s'appuyer sur LINQ to SQL et plus Entity Framework, le projet Contact manager compile sans problème. Encore faut-il penser à modifier la couche de service pour instancier un objet IContactManagerRepository à partir de L2SContactManagerRepository :

public ContactManagerService(IValidationDictionary validationDictionary)
    : this(validationDictionary, new L2SContactManagerRepository())
{
}

Par contre, la compilation de la solution provoque une erreur parce que les tests unitaires font appel à la méthode CreateContact() de la classe Contact. Apparemment, Entity Framework génère automatiquement une méthode CreateContact() pour ses objets, alors que LINQ to SQL n'en fait rien !

Cela met en évidence deux problèmes :

• chez Microsoft, ils sont si peu opiniated qu'ils partent dans tous les sens
• les tests unitaires du Contact Manager sont fortement liés à l'ORM Entity Framework et ça, c'est pas bon du tout

Dans un premier temps, j'ai tout simplement piraté la méthode CreateContact() générée par Entity Framework et ajouté une classe partielle Contact :

namespace ContactManager.Models
{
    public partial class Contact
    {
        /// <summary>
        /// Create a new Contact object.
        /// </summary>
        /// <param name="id">Initial value of Id.</param>
        /// <param name="firstName">Initial value of FirstName.</param>
        /// <param name="lastName">Initial value of LastName.</param>
        /// <param name="phone">Initial value of Phone.</param>
        /// <param name="email">Initial value of Email.</param>
        public static Contact CreateContact(int id, string firstName, string lastName, string phone, string email)
        {
            Contact contact = new Contact();
            contact.Id = id;
            contact.FirstName = firstName;
            contact.LastName = lastName;
            contact.Phone = phone;
            contact.Email = email;
            return contact;
        }
    }
}

Mais j'ai trouvé ça un peu trop spécifique pour LINQ to SQL (puisque c'est redondant avec le code généré par Entity Framework) et j'ai finalement préféré ajouter une méthode CreateContact() utilisant la syntaxe "Object initializers" à la classe ContactManagerServiceTest des tests unitaires :

private Contact CreateContact(int id, string firstName, string lastName, string phone, string email)
{
    Contact contact = new Contact() { Id = id, FirstName = firstName, LastName = lastName, Phone = phone, Email = email };
    return contact;
}

Puis remplacer les appels à Contact.CreateContact() dans ContactManagerServiceTest.cs par de simples appels à CreateContact().

Une fois cette dernière modification réalisée, la solution compile sans erreur, les tests unitaires continuent à être OK et l'application fonctionne sans problème. Je peux :

• lister les contacts rattachés à un groupe,
• ajouter, modifier ou supprimer un contact,
• ajouter ou supprimer un groupe de contacts.

Conclusion

Suite à mes différents essais avec les tutoriels ContactManager et NerdDinner, j'avais eu le pressentiment que cette notion de repository et de service pouvait rendre une application indépendante de la façon d'implémenter l'accès à la base de données.

La réalisation de ce petit exercice m'a permis de vérifier cette impression puisque hormis une ligne de la couche service, seule la classe Repository a été mise à jour. Par conséquent, si on fait les choses comme il faut, on ne se retrouve pas lié corps et âme à un ORM mais au contraire complètement libre d'en changer dans le cas où il ne serait pas satisfaisant.

Dans la pratique, cela veut dire qu'il ne faut pas se focaliser sur des détails techniques mais sur des problèmes réels. Et notamment décider si on conserve une base de données pourrie pléthorique et mal conçue ou si on fait table rase des errements du passé pour construire une vrai base de données et de vrais objets adaptés uniquement à nos besoins actuels.

C'est la dernière ligne droite : plus que 14 pages de tutoriel à avaler et je pourrai cocher la case "Finir le tutoriel de Gestion de Contacts" de ma totolist. Pour cette 7° partie, il va s'agir d'ajouter le support d'Ajax à notre gestion de contacts en ASP.NET MVC, dans le but d'améliorer ses performances et son ergonomie (en quelque sorte donner l'impression à l'utilisateur qu'il est en train d'utiliser une application Windows).

Les deux premières pages passent comme une lettre à la poste : pourquoi utiliser Ajax, ce qu'on va faire avec, Ajax c'est gentil... Il faut juste faire attention à la version du jQuery disponible dans le dossier Scripts.

Utilisation d'une vue partielle avec Ajax

Puis on s'attaque au vif du sujet pour modifier la vue Index des contacts, afin déviter de recharger toute la page juste quand on change de groupe de contacts.

Pour commencer, on utilise une vue partielle qui sera chargé d'afficher la table html contenant les contacts rattachés au groupe sélectionné. Concrètement, on fait un contrôle utilisateur .ASCX dans lequel on déporte tout le code générant la <table> qui existe actuellement dans la vue Index.aspx

Ce qui nous donne le fichier Views\Contact\ContactList.ascx suivant :

<%@ Control Language="C#" Inherits="System.Web.Mvc.ViewUserControl<ContactManager.Models.Group>" %>
<%@ Import Namespace="Helpers" %>
<table class="data-table" cellpadding="0" cellspacing="0">
    <thead>
        <tr>
            <th class="actions edit">
                Edit
            </th>
            <th class="actions delete">
                Delete
            </th>
            <th>
                Name
            </th>
            <th>
                Phone
            </th>
            <th>
                Email
            </th>
        </tr>
    </thead>
    <tbody>
        <% foreach (var item in Model.Contacts)
           { %>
        <tr>
            <td class="actions edit">
                <a href='<%= Url.Action("Edit", new {id=item.Id}) %>'><img src="../../Content/Edit.png" alt="Edit" /></a>
            </td>
            <td class="actions delete">
                <a href='<%= Url.Action("Delete", new {id=item.Id}) %>'><img src="../../Content/Delete.png" alt="Delete" /></a>
            </td>
            <td>
                <%= Html.Encode(item.FirstName) %> <%= Html.Encode(item.LastName) %>
            </td>
            <td>
                <%= Html.Encode(item.Phone) %>
            </td>
            <td>
                <%= Html.Encode(item.Email) %>
            </td>
        </tr>
        <% } %>
    </tbody>
</table>

Et on remplace ce code par une simple ligne :

<% Html.RenderPartial("ContactList", Model.SelectedGroup); %>

Ce qui fait que notre fichier Contact\Index.aspx ne contient plus que le code ci-dessous :

<%@ Page Title="" Language="C#" MasterPageFile="~/Views/Shared/Site.Master" Inherits="System.Web.Mvc.ViewPage<ContactManager.Models.ViewData.IndexModel>" %>
<%@ Import Namespace="Helpers" %>

<asp:Content ID="Content1" ContentPlaceHolderID="TitleContent" runat="server">
        Index
</asp:Content>

<asp:Content ID="Content2" ContentPlaceHolderID="MainContent" runat="server">

<div class="container">
    
    <ul id="leftColumn">
    <% foreach (var item in Model.Groups) { %>
        <li<%= Html.Selected(item.Id, Model.SelectedGroup.Id) %>>
            <%= Html.ActionLink(item.Name, "Index", new { id = item.Id }) %>
        </li>
    <% } %>
    </ul>

    <div id="divContactList">
        <% Html.RenderPartial("ContactList", Model.SelectedGroup); %>
    </div>
    
    <div class="clear"></div>

</div>

</asp:Content>

Perso, je ne vais même pas plus loin et je lance le tout pour vérifier que tout fonctionne correctement. Il me faut quand même supprimer ContactList.ascx.cs mais au final ça marche sans problème.

Donc, même sans faire d'Ajax, cette vue partielle permet de simplifier le code dans le cas de vues un peu compliquées, en évitant de tout faire au même endroit...

Ensuite, si on veut vraiment faire de l'Ajax, il faut faire en sorte que quand on clique sur un des groupes dans la 1° colonne, au lieu de redemander l'action Index avec un autre groupId, on fasse seulement un appel à une fonction Ajax pour ne récupérer que le résultat de cette vue partielle avec les contacts correspondant au groupId sélectionné.

Pour cela, on remplace la méthode Html.ActionLink() par une méthode Ajax.ActionLink()

<%= Ajax.ActionLink(item.Name, "Index", new { id = item.Id }, new AjaxOptions { UpdateTargetId = "divContactList"})%>

Ce coup-ci, je ne me fais pas avoir et je vérifie directement pour voir s'il s'agit d'un Html Helper standard de ASP.NET MVC ou s'il a été fait à la main pour le tutoriel. Rien de nouveau dans le dossier Helpers => c'est du standard.

Donc, du côté de la vue on fait en sorte de faire un appel Ajax pour demander la mise à jour du contenu. Par conséquent, il faut qu'il y ait du répondant côté contrôleur. Pour cela, nous devons modifier l'action Index pour qu'elle gère le cas où elle est invoquée dans le cadre d'une demande Ajax.

Et dans ce cas, elle ne renvoie que la vue partielle destinée à afficher la liste des contacts et pas toute la vue Contact\Index.

public ActionResult Index(int? id)
{
    // Get selected group
    var selectedGroup = _service.GetGroup(id);
    if (selectedGroup == null)
        return RedirectToAction("Index", "Group");

    // Ajax Request
    if (Request.IsAjaxRequest())
        return PartialView("ContactList", selectedGroup);
    
    // Normal Request
    var model = new IndexModel
    {
        Groups = _service.ListGroups(),
        SelectedGroup = selectedGroup
    };
    return View("Index", model);
}

Je compile, j'exécute et tout marche comme prévu dans le tutoriel. Y compris le fait que le groupe sélectionné n'est pas mis en évidence (puisqu'il n'y a pas de classe "selected").

Ajout d'une animation jQuery

Pour résoudre le petit problème de CSS et aussi pour que l'utilisateur se rende compte qu'il se passe quelque chose, on va utiliser la librairie jQuery (qui est incluse dans le framework ASP.NET MVC) pour :

• changer la classe CSS du groupe sélectionné
• ajouter une animation pour que l'utilisateur comprenne qu'il se passe quelque chose

C'est assez simple à faire puisque dans les options Ajax on dispose des évènements OnBegin, OnSuccess et OnFailure :

<%= Ajax.ActionLink(item.Name, "Index", new { id = item.Id }, new AjaxOptions { UpdateTargetId = "divContactList", OnBegin = "beginContactList", OnSuccess = "successContactList", OnFailure = "failureContactList" })%>

Ce qui nous permet de définir les fonctions Javascript à appeller quand :

• la requête Ajax va commencer
• la requête Ajax s'est terminée correctement
• la requête Ajax a échoué

<script type="text/javascript">

    function beginContactList(args) {
        // Highlight selected group
        $('#leftColumn li').removeClass('selected');
        $(this).parent().addClass('selected');
        // Animate
        $('#divContactList').fadeOut('normal');
    }

    function successContactList() {
        // Animate
        $('#divContactList').fadeIn('normal');
    }

    function failureContactList() {
        alert("Could not retrieve contacts.");
    }

</script>

Ajout du support de l'historique du navigateur

J'ai lu cette partie, mais c'est tout. Utiliser Ajax pour faire croire à un utilisateur qu'il est dans une application Windows puis faire des bidouilles interminables pour qu'il retrouve des automatismes du monde web, très peu pour moi.

Faire des suppressions en Ajax

Ca c'est quelque chose de beaucoup plus intéressant. Pas vraiment d'un point de vue interface utilisateur (je préfère afficher un écran de détail où on voit clairement la fiche qui va être supprimée si on confirme), mais plus pour le côté "si je veux faire une suppression, j'utilise une méthode HTTP DELETE".

Pour commencer, il faut remplacer l'image du lien "Supprimer" par un nouveau Helper ImageActionLinkHelper.cs créé spécialement. Son but est simplement de nous permettre d'avoir une méthode Ajax.ActionLink() associé à l'image utilisée pour matérialiser l'action de suppression.

Le nouveau helper Ajax.ImageActionLink() gère l'appel Ajax côté client et côté serveur on ajoute une nouvelle action AjaxDelete au contrôleur Contact.

[AcceptVerbs(HttpVerbs.Delete)]
[ActionName("Delete")]
public ActionResult AjaxDelete(int id)
{
    // Get contact to delete
    Contact contactToDelete = _service.GetContact(id);

    // Get group from the contact
    var selectedGroup = _service.GetGroup(contactToDelete.Group.Id);

    // Delete from database
    _service.DeleteContact(contactToDelete);

    // Return Contact List
    return PartialView("ContactList", selectedGroup);
}

Cette action a deux particularités :

• L'attribut [AcceptVerbs(HttpVerbs.Delete)] la rend utilisable seulement dans le cas d'une opération HTTP DELETE (et donc pas via un simple GET ou POST)
• L'attribut [ActionName("Delete")] sert à avoir un nom d'action ("Delete") qui est différent du nom de la méthode ("AjaxDelete")

Il est à noter que dans le cas où Javascript est désactivé, la suppression d'un contact continue de fonctionner :

• un clic sur l'image "Supprimer" fait suivre le lien /Contact/Delete/123
• le lien /Contact/Delete/123 correspond à l'action Delete(int id) d'origine en mode GET qui renvoie la vue Delete.aspx pour faire confirmer
• un clic sur le bouton "Delete" pour confirmer effectue un POST vers /Contact/Delete/123
• un post sur /Contact/Delete/123 correspond à l'action Delete(Contact contactToDelete) en mode POST qui supprime le contact et renvoie la vue Index.

Conclusion

Ouf ! Ca a été long (plus d'un mois) et pas toujours facile, mais j'ai finalement réussi à suivre ce tutoriel d'un bout à l'autre. Avec du recul, je me rend compte qu'il aurait été préférable de suivre les tutoriels ASP.NET MVC dans l'ordre, plutôt que d'attaquer directement avec l'exercice de fin de cours ! Mais il n'est jamais trop tard pour bien faire, surtout maintenant que la traduction française est disponible. Je vais donc pouvoir continuer mon apprentissage avant de retrouver le tutoriel NerdDinner.

Plus tard, j'aimerais utiliser cette application de Gestion de Contacts comme une base. Je pense qu'il serait intéressant de la refaire en remplaçant Entity Framework par LINQ to SQL et voir ce que cela change et en particulier si les différences sont bien cantonnées au niveau du repository. Et puis continuer en testant ça avec SubSonic ou NHibernate, en particulier avec Fluent NHibernate...

Billet suivant dans la série : Gestion de contacts avec ASP.NET MVC et jQuery

Je dois avouer que j'ai pas mal dévié de l'objectif de cette 6° partie du tutoriel de Gestion des Contacts. Son but était d'illustrer l'intérêt du test-driven-development en prenant pour exemple l'ajout d'une notion de groupes de contacts. Comme je trouvais que la fin du tutoriel passait un peu vite sur la réalisation concrète des modifications réalisées et que je ne voulais pas me contenter de les récupérer toutes faites, j'ai pris ça comme un exercice pour compléter mon apprentissage d'ASP.NET MVC.

Première tentative

Dans ce billet, je vais donc continuer la modification de la base de données, c'est à dire ajouter une colonne groupId à la table des contacts et définir une relation entre les deux tables Contacts et Groups.

Je commence par l'ajout de la colonne groupId de type int, en prenant soin de définir sa propriété "Default Value or Binding" à 1. Cette petite astuce m'évite d'avoir à vider la table des contacts lorsque j'ajoute la relation entre cette nouvelle colonne et la table Groups créée la fois précédente.

Puis je m'occupe de la mise à jour du modèle. Mais ça ne se fait pas tout seul :( Je dois passer par la toolbox pour ajouter l'association entre les deux tables. Et même après ça, j'ai des erreurs de compilation ! je recommence, je bidouille, mais rien à faire, ça ne veut pas compiler...

Seconde tentative

Pour aller plus vite, je récupère la base de données (App_Data\ContactManagerDB*.*) et le modèle (Models\ContactManagerModel.*) qui datent d'avant l'ajout de la table "Groups" et je refais tout comme indiqué dans le tutorial (ou à peu près).

• ajout de la table "Groups"
• création d'un premier groupe "Business"
• ajout de la colonne "groupId" à la table "Contacts", en mettant 1 comme "Default Value or Binding"
• définition de la relation entre les deux tables
• mise à jour du modèle

Et cette fois-ci, tout marche comme sur des roulettes ! Je vérifie que ça compile (Ok), je quitte VWD et je sauvegarde. On ne sait jamais...

Prise en compte de groupId dans la table Contacts

Pour la suite, je vais déjà tenter de faire apparaitre la liste des groupes dans les formulaires de création et de mise à jour des contacts, mais juste pour l'affichage, sans chercher à en tenir compte pour enregistrer les contacts.

Je commence par modifier la classe EntityContactManagerRepository.cs pour modifier les requêtes LINQ et leur ajouter les .Include() afin de gérer la relation entre les tables :

...
public Contact GetContact(int id)
{
    return (from c in _entities.ContactSet.Include("Group")
            where c.Id == id
            select c).FirstOrDefault();
}
...
public Group GetGroup(int id)
{
    return (from g in _entities.GroupSet.Include("Contacts")
            where g.Id == id
                    select g).FirstOrDefault();
}
...

J'exécute et je teste l'ajout d'un groupe "Friends" et ça passe. J'essaie alors de créer un nouveau contact mais là le clic sur le bouton "Create" n'a plus aucun effet. Un petit débugage m'apprend que _entities.SaveChanges() ne fonctionne plus.

Qu'à cela ne tienne, je fais une autre modification au repository pour associer le contact à créer au groupe par défaut juste avant de procéder à son enregistrement et là ça marche.

public Contact CreateContact(Contact contactToCreate)
{
    // Associate group with contact
    contactToCreate.Group = GetGroup(1);

    // Save new contact
    _entities.AddToContactSet(contactToCreate);
    _entities.SaveChanges();
    return contactToCreate;
}

Et ça marche même pour la mise à jour sans qu'il n'y ait rien d'autre à faire. Tant mieux.

Bon. Aux vues maintenant.

Mise à jour des vues contacts pour lister les groupes

Je démarre avec la vue Create.aspx en regardant comment c'est fait dans les sources finis de la 6° partie et en refaisant la même chose pas à pas.

Ajouter une dropdown list des groupes dans le formulaire Views\Contact\Create/aspx :

<p>
    <label for="GroupId">Group:</label>
    <%= Html.DropDownList("GroupId") %>
</p>

Tel quel, ça reste insuffisant et on obtient une erreur «There is no ViewData item with the key 'GroupId' of type 'IEnumerable<SelectListItem>'.» quand on essaie d'afficher le formulaire de création d'un contact.

Il faut donc que le contrôleur fasse passer la liste des groupes à la vue :

public ActionResult Create()
{
    if (!AddGroupsToViewData(-1))
        return RedirectToAction("Index", "Group");
    return View("Create");
}

protected bool AddGroupsToViewData(int selectedId)
{
    var groups = _service.ListGroups();
    ViewData["GroupId"] = new SelectList(groups, "Id", "Name", selectedId);
    return groups.Count() > 0;
}

La fonction AddGroupsToViewData() ajoute la liste des groupes à la collection ViewData et dans le cas où cette collection serait vide, le contrôleur redirige l'utilisateur vers la liste des groupes afin qu'il puisse y créer au moins un nouveau groupe.

Pour que cela fonctionne, il faut encore ajouter using System.Linq;, sinon la syntaxe groups.Count() n'est pas acceptée.

Après avoir vérifié que ça marche bien, j'en ai profité pour présenter les noms des groupes dans l'ordre alphabétique. Après pas mal de Google, j'ai trouvé comment faire :

public IEnumerable<Group> ListGroups()
{
    return _entities.GroupSet.OrderBy(o => o.Name).ToList();
}

C'est quand même plus joli.

Je continue donc avec la vue Edit.aspx où je refais quasiment la même chose.

Ca avance ! Je peux maintenant associer un contact au groupe de contacts de mon choix. Y'a plus qu'à faire en sorte que ce choix soit enregistré dans la base de données.

Mais avant, je ne résiste pas au plaisir de trier aussi la liste des contacts :

public IEnumerable<Contact> ListContacts()
{
    return _entities.ContactSet.OrderBy(o => o.FirstName).ThenBy(o => o.LastName).ToList();
}

Utilisation du groupe sélectionné pour créer un contact

Maintenant, je vais essayer de tenir compte du groupe sélectionné lors de la création d'un contact.

Pour cela, il faut théoriquement :

• récupérer l'identifiant du groupe sélectionné dans le formulaire
• utiliser cet identifiant au moment de l'enregistrement du contact, en lieu et place du "1" que j'avais mis en dur

Facile ! Si je regarde le code fini de la 6° partie, un paramètre int groupId a été ajouté à l'action Create de ContactController.cs.

[AcceptVerbs(HttpVerbs.Post)]
public ActionResult Create(int groupId, [Bind(Exclude = "Id")] Contact contactToCreate)
{
    if (_service.CreateContact(contactToCreate))
        return RedirectToAction("Index");
    AddGroupsToViewData(-1);
    return View("Create");
}

Et pour que ça marche, il faut aussi modifier ContactControllerTest.cs qui teste cette action en donnant la valeur 1 à ce nouveau paramètre.

Donc pour l'instant le contrôleur récupère l'identifiant du groupe qui a été choisi. Il faut ensuite trouver comment faire suivre cet identifiant au repository pour qu'il en tienne compte. J'aurai eu tendance à écrire contactToCreate.groupId = groupId, mais malheureusement l'objet Contact n'a pas de propriété groupId.

Il faut donc procéder pas à pas et commencer par faire passer le groupId du contrôleur au service : _service.CreateContact(contactToCreate) devient _service.CreateContact(groupId, contactToCreate), ce qui implique de modifier IContactManagerService.cs, ContactManagerService.cs et ContactManagerServiceTest.cs

Puis ensuite faire suivre le groupId du service au repository, ce qui nécessite la mise à jour de IContactManagerRepository.cs, EntityContactManagerRepository.cs et FakeContactManagerRepository.cs

1. ContactController.cs récupère groupId de la vue et l'envoie au service

[AcceptVerbs(HttpVerbs.Post)]
public ActionResult Create(int groupId, [Bind(Exclude = "Id")] Contact contactToCreate)
{
    if (_service.CreateContact(groupId, contactToCreate))
        return RedirectToAction("Index");
    AddGroupsToViewData(-1);
    return View("Create");
}

2. ContactManagerService.cs récupère groupId du contrôleur et l'envoie au repository

public bool CreateContact(int groupId, Contact contactToCreate)
{
    // Validation logic
    if (!ValidateContact(contactToCreate))
        return false;

    // Database logic
    try
    {
        _repository.CreateContact(groupId, contactToCreate);
    }
    catch
    {
        return false;
    }
    return true;
}

3. EntityContactManagerRepository.cs : récupère groupId du service et l'utilise pour créer le contact

public Contact CreateContact(int groupId, Contact contactToCreate)
{
    // Associate group with contact
    contactToCreate.Group = GetGroup(groupId);

    // Save new contact
    _entities.AddToContactSet(contactToCreate);
    _entities.SaveChanges();
    return contactToCreate;
}

Je lance l'application et crée un nouveau contact après avoir sélectionné "Friends" dans la dropdown list des groupes, je clique sur le bouton "Create" et ça marche ! Faut vérifier dans la table Contacts pour le croire mais c'est bien le cas.

Utilisation du groupe pour modifier un contact

Ca consiste très simplement à refaire à peu près pareil avec la vue Edit.aspx et les méthode Edit() qu'on trouve un peu partout dans le contrôleur, le service et le repository.

Déjà il faut faire en sorte que la vue Edit.aspx fasse apparaitre correctement le groupe auquel le contact a été rattaché. Pour cela, il suffit que le contrôleur lui donne la bonne information :

public ActionResult Edit(int id)
{
    var contactToEdit = _service.GetContact(id);
    AddGroupsToViewData(contactToEdit.Group.Id);
    return View(contactToEdit);
}

Au moins maintenant quand je vais en modification du contact que je viens de créer, c'est bien le "Friends" qui apparait sélectionné dans la dropdown list des groupes.

Reste plus qu'à refaire les 3 étapes pour que le groupe sélectionné au niveau de la vue Edit.aspx soit transmis jusqu'au niveau du repository.

1. ContactController.cs récupère groupId de la vue et l'envoie au service

[AcceptVerbs(HttpVerbs.Post)]
public ActionResult Edit(int groupId, Contact contactToEdit)
{
    if (_service.EditContact(groupId, contactToEdit))
        return RedirectToAction("Index");
    AddGroupsToViewData(groupId);
    return View("Edit");
}

2. ContactManagerService.cs récupère groupId du contrôleur et l'envoie au repository

public bool EditContact(int groupId, Contact contactToEdit)
{
    // Validation logic
    if (!ValidateContact(contactToEdit))
        return false;

    // Database logic
    try
    {
        _repository.EditContact(groupId, contactToEdit);
    }
    catch
    {
        return false;
    }
    return true;
}

3. EntityContactManagerRepository.cs : récupère groupId du service et l'utilise pour mettre à jour le contact

public Contact EditContact(int groupId, Contact contactToEdit)
{
    // Get original contact
    var originalContact = GetContact(contactToEdit.Id);
    
    // Update with new group
    originalContact.Group = GetGroup(groupId);
    
    // Save changes
    _entities.ApplyPropertyChanges(originalContact.EntityKey.EntitySetName, contactToEdit);
    _entities.SaveChanges();
    return contactToEdit;
}

Quel progrès ! Je peux enfin rattacher un contact à un groupe au moment de sa création et même en changer lors de sa modification, et tout ça pour de vrai. Et sans compter que les tests unitaires sont toujours au vert.

Je touche au but

Pour enfin arriver au bout de cette 6° étape, il me reste juste à faire apparaitre les groupes au niveau de la vue Contact\Index.aspx qui affiche la liste des groupes. Malheureusement pour moi, le tutoriel n'a pas choisi la facilité en se contentant d'ajouter une colonne "Group" à cette liste mais a préféré filtrer la liste par groupe.

Juste pour le fun, je commence par essayer d'ajouter une colonne "Group" à la liste en modifiant Contact\Index.aspx :

<td>
    <%= Html.Encode(item.Group.Name) %>
</td>

Mais à l'exécution, ça ne passe pas et j'ai une erreur «La référence d'objet n'est pas définie à une instance d'un objet.» à cause de item.Group.Name. Je fais des progrès parce que je comprend de suite que la liste des contacts que le contrôleur ContactController.cs fait passer à la vue n'a pas été modifiée pour y faire apparaitre le groupe.

Une très légère modification à EntityContactManagerRepository.cs et c'est résolu :

public IEnumerable<Contact> ListContacts()
{
    return _entities.ContactSet.Include("Group").OrderBy(o => o.FirstName).ThenBy(o => o.LastName).ToList();
}

J'en serais bien resté là, mais la septième (et dernière !) étape du tutoriel va modifier cette vue Index pour utiliser Ajax. Si je veux vraiment aller jusqu'au bout de ce tutoriel il va falloir que j'en passe par le filtrage des contacts en fonction du groupe...

Je supprime donc mes modifications et c'est reparti.

Pour ce qui concerne la vue, je fais du copier / coller depuis le résultat du tutoriel, parce que c'est un peu tard et que je n'ai plus le courage de tout faire moi même. De toute façon, le principe est assez simple. On commence par faire deux blocs dans le html, le premier avec la liste des groupes (c'est le <ul id="leftColumn">) et le second avec la table des contacts (le <div id="divContactList">).

<ul id="leftColumn">
<% foreach (var item in Model.Groups) { %>
    <li <%= Html.Selected(item.Id, Model.SelectedGroup.Id) %>>
    <%= Html.ActionLink(item.Name, "Index", new { id = item.Id }) %>
    </li>
<% } %>
</ul>

<div id="divContactList">
    <table class="data-table" cellpadding="0" cellspacing="0">
        <thead>
            <tr>
                ...
            </tr>
        </thead>
        <tbody>
            <% foreach (var item in Model.SelectedGroup.Contacts)
               { %>
            <tr>
                ...
            </tr>
            <% } %>
        </tbody>
    </table>
</div>    

Puis on ajoute un peu de CSS pour faire flotter tout ça que les deux blocs apparaissent côte à côte.

F5 pour voir ce que ça donne... et c'est la grosse erreur :

c:\MVC\ContactManager\ContactManager\Views\Contact\Index.aspx(12): error CS1061: 'System.Collections.Generic.IEnumerable<ContactManager.Models.Contact>' ne contient pas une définition pour 'Groups' et aucune méthode d'extension 'Groups' acceptant un premier argument de type 'System.Collections.Generic.IEnumerable<ContactManager.Models.Contact>' n'a été trouvée (une directive using ou une référence d'assembly est-elle manquante ?)

Comme maintenant je commence à être doué, je vois très vite que la vue Index hérite toujours de System.Web.Mvc.ViewPage<IEnumerable<ContactManager.Models.Contact>> et que par conséquent il n'y a rien pour remplir la liste des groupes. Zut alors, il fallait aussi que je copie / colle la première ligne de l'Index.aspx du tutoriel.

<%@ Page Title="" Language="C#" MasterPageFile="~/Views/Shared/Site.Master" Inherits="System.Web.Mvc.ViewPage<ContactManager.Models.ViewData.IndexModel>" %>

Attendez-voir. Y'a un IndexModel. Il sort d'où lui ?

Je relance l'application pour la forme, mais je sais bien que ça va planter.

c:\WINDOWS\Microsoft.NET\Framework\v2.0.50727\Temporary ASP.NET Files\root\01b85515\43ff20e2\App_Web_index.aspx.ebd9867.w7_tnpa3.0.cs(148): error CS0234: Le type ou le nom d'espace de noms 'ViewData' n'existe pas dans l'espace de noms 'ContactManager.Models' (une référence d'assembly est-elle manquante ?)

Finalement, c'est pas ce soir que je vais finir...

Billet suivant dans la série : Test-Driven Development avec ASP.NET MVC (fin)

Je continue ma formation ASP.NET MVC avec la suite de la 6° partie du tutoriel pour gérer des contacts qui est consacrée à la Programmation Pilotée par les Tests (ou Test-Driven Development en anglais).

Point de départ

Jusqu'ici, j'ai donc abordé les deux premières étapes sur les trois que compte la méthode TDD :

1. Ecrire un test unitaire qui échoue (Rouge)
2. Ecrire un code qui passe le test unitaire avec succès (Vert)
3. Revoir l’architecture de votre code (Refactoring)

Pour résumer l'épisode précédent, il fallait modifier l'application des gestion de contacts pour ajouter une notion de groupe de contacts. Comme point de départ, on avait 3 scénarios utilisateur (lister les groupes, créer un groupe et valider un groupe) et on a appliqué les 2 premières étape du TDD :

• Etape 1 : on écrit des tests unitaires pour vérifier les fonctionnalités attendues (et ces tests échouent car non compilables)
• Etape 2 : on écrit le minimum de code pour que les tests unitaires réussissent

Refactoring

J'en arrive donc à l'étape 3 : revoir l’architecture du code (refactoriser). Aux deux premières étapes du TDD, l'objectif est de se concentrer sur les tests unitaires destinés à vérifier que les fonctionnalités sont biens implémentées, sans se prendre la tête sur la "bonne" façon de faire. Ce n'est qu'à partir de cette troisième étape qu'il faut chercher à produire du "bon" code. Et on peut toucher à notre premier jet de code l'esprit libre, puisqu'on s'est blindé grâce à nos tests unitaires qui vont nous empêcher de casser quoi que ce soit d'important.

Dans le cas présent, le refactoring va consister à réviser le code du contrôleur GroupController qui mélange un peu tout pour le rendre plus conforme au Single Responsibility Principle comme on l'avait déjà fait dans la 4° partie du tutoriel pour le contrôleur ContactController.

Pour cela, on va modifier le contrôleur pour qu'il utilise la couche de service ContactManagerService que l'on avait mis en place pour le contrôleur ContactController. C'est assez simple et il suffit de taper le code source fourni dans le tutoriel. Il y manque quelques using ContactManager.Models.Validation; et il faut bien penser à modifier aussi les fichiers interfaces, mais c'est OK pour la 3° étape du TDD.

Ca avance, mais je me pose quand même des questions.

• Est-ce que ça prendrait vraiment beaucoup plus de temps si on avait fait "bien" dès le premier coup ?
• Et même, est-ce qu'une fois qu'on a l'habitude d'utiliser les couches service et repository, est-ce que ce n'est pas plus long de se souvenir comment écrire du code qui ne s'en sert pas ?
• Et surtout, il n'y a pas de 4° étape dans le TDD et pourtant je n'ai encore rien qui gère des groupes de contacts pour de "vrai" !

Coup d'oeil en arrière

Sinon, cette partie du tutoriel m'a fait prendre conscience d'un truc auquel je n'avais pas fait attention lors de la partie sur le refactoring. En fait, la classe repository et la classe service servent pour toute l'application et pas seulement dans le cas de la table Contact. C'est d'ailleurs pour ça qu'elles s'appellent ContactManagerRepository et ContactManagerService et pas seulement ContactRepository et ContactService.

Ca non plus, je sais pas trop si ça me plait bien. J'ai un peu peur qu'à la fin on risque de se retrouver avec un source énorme si notre application doit gérer un très grand nombre de tables. Sans compter que ça devient génant dans le cas des FakeRepository où on devra donc tout implémenter à coup de throw new NotImplementedException() (et revenir dessus en permanence dès qu'on ajoutera des signatures à l'interface).

Mais je suppose qu'il n'est pas totalement incongru d'avoir des "sous" repository pour différents tables (ou peut-être des classes partielles ?). A voir...

Sous le coude

Je vais continuer avec la suite de cette 6° partie qui va enfin s'attaquer à la réalisation des fonctionnalités pour de "vrai". Mais si j'ai un peu de temps, j'aimerai bien essayer d'approfondir tout ça pour voir comment implémenter les autres scénarios utilisateurs selon la méthode TDD :

• L’utilisateur peut supprimer un groupe de contacts existant
• L’utilisateur peut sélectionner un groupe lorsqu’il crée un nouveau contact
• L’utilisateur peut sélectionner un groupe lorsqu’il édite un contact existant
• La liste des groupes de contacts est affichée dans la vue Index
• Lorsqu’un utilisateur clique sur un groupe, la liste de contacts associée est affichée

(Bien que pour l'instant je ne vois pas trop quel test unitaire faire pour vérifier la suppression d'un groupe de contacts.)

Ou en attendant tout ça, deux liens assez intéressant sur les TDD :

• Une initiation au Développement piloté par les Tests sur le site de Ruby France
• Un compte-rendu d'une formation au TDD par Olivier Duval

Billet suivant dans la série : Test-Driven Development avec ASP.NET MVC (suite)

La cinquième étape du tutoriel pour développer une application de gestion de contacts avec ASP.NET MVC concerne les tests unitaires : à quoi cela sert, comment les utiliser et les créer... puis aborde la réalisation d'un premier jeu de tests unitaires pour contrôler le bon fonctionnement de la couche de service et un autre pour vérifier le fonctionnement du contrôleur.

Rendre NUnit compatible avec Visual Studio Unit Test

Pour commencer, comme je fais mes essais avec Visual Web Developer et pas Visual Studio 2008, je ne peux pas utiliser Visual Studio Unit Test, le framework de test par défaut. A sa place, j'utilise NUnit et pour l'instant je n'ai pas rencontré trop de problème (mais il est vrai que je n'ai pas encore fait grand chose...).

Ce coup-ci, cela devient un peu plus sérieux et il s'agit dans un premier temps de saisir une ou deux pages de tests unitaires pour tester le service ContactManagerService. J'ai carrément triché et fait du copié / collé pour d'avoir tout à saisir moi-même, mais le plus embêtant, c'est que le code proposé par le tutoriel ne fonctionne pas avec NUnit :(

Premier truc pas si compliqué à trouver : il faut supprimer la référence au framework Visual Studio Unit Test

using Microsoft.VisualStudio.TestTools.UnitTesting;

et la remplacer par une référence à NUnit :

using NUnit.Framework;

C'était malin, mais pas suffisant... Le couple VWD + NUnit n'aime pas du tout les attributs [TestClass], [TestInitialize] et [TestMethod] et me le fait savoir :

• The type or namespace name 'TestClassAttribute' could not be found
• The type or namespace name 'TestClass' could not be found
• The type or namespace name 'TestInitializeAttribute' could not be found
• The type or namespace name 'TestInitialize' could not be found
• The type or namespace name 'TestMethodAttribute' could not be found
• The type or namespace name 'TestMethod' could not be found

Après quelques recherches, j'ai finalement trouvé la solution chez static void (NUnit/MSTest Dual Testing). Il suffit d'ajouter quelques "usings" au début du source pour que NUnit accepte les mêmes attributs que VS Unit Test :

using TestClass = NUnit.Framework.TestFixtureAttribute;
using TestMethod = NUnit.Framework.TestAttribute;
using TestInitialize = NUnit.Framework.SetUpAttribute;
using TestCleanup = NUnit.Framework.TearDownAttribute;
using TestContext = System.Object;

Encore deux petites remarques :

• VWD ne proposant pas l'option "Add / New Test / Unit Test", il faut choisir "Add / New Item / Class"
• La méthode .Expect() de Moq a été remplacée par .Setup()

Sur quoi faire porter les tests unitaires

Sinon, l'étude de cette cinquième partie m'en a un peu plus appris sur l'intérêt des tests unitaires, notamment sur quoi les faire porter (la couche métier) ou plus exactement sur quoi "éviter" de les faire poster (la présentation et l'accès aux données). L'idée, c'est que les tests unitaires doivent s'exécuter très très très rapidement, sinon on risque de les laisser tomber, sauf si on est très joueur...

Il ne faut donc pas faire de tests unitaires sur l'interface utilisateur, parce que puisque on est en ASP.NET, cela exige le lancement d'un serveur Web ce qui ralentira la réalisation des tests. C'est une des raisons qui fait que MVC est "mieux" que les WebForms. Dans MVC, la View qui est la partie interface utilisateur n'est pas faite pour contenir du code (ce qui fait qu'on a pas à le tester !). Dans le cas des WebForms, où tout est plus ou moins mélangé, il est plus difficile d'isoler le code de la présentation.

Il ne faut pas non plus faire de tests sur l'accès aux bases de données. Si on doit en passer par une vraie base de données, le temps d'exécution des tests unitaires va devenir beaucoup trop long. Et c'est là que l'empilement des couches évoqué dans la partie précédente dévoile tout son intérêt. On va "émuler" l'accès à la base de données grâce à des classes Mock qui simulent l'implémentation de l'interface IRepository vue précédemment, sans réellement interagir avec la base de données. Par conséquent, la réalisation de cette interface IRepository ne doit pas être ressentie comme un niveau de complexité supplémentaire et inutile mais comme une étape clé pour faciliter la mise en place de tests unitaires.

Sous le coude

La sixième étape du tutoriel va consister à ajouter une fonctionnalité à la gestion des contacts. Cela promet d'être très intéressant car on va pour cela bouleverser l'application en introduisant la notion de groupe de contacts. Et ce coup-ci on va d'abord créer les tests unitaires à priori, dans le but d'encadrer la programmation des modifications.

Et à lire pour plus tard, un article d'une quinzaine de pages en français sur les tests unitaires en pratique par Patrick Smacchia. Dans un premier temps, il présente comment réaliser des tests unitaires et les bénéfices que l'on peut en retirer. La seconde partie est consacrés aux problèmes de mise en oeuvre que l'on peut rencontrer (il aborde un peu plus en détail les problématiques liées à l'accès à la base de données) et comment les résoudre.

Billet suivant dans la série : Test-Driven Development avec ASP.NET MVC

La fois d'avant, j'avais seulement fait la toute première étape du tutoriel NerdDinner de Scott Guthrie, à savoir :

• créer le projet NerdDinner,
• vérifier qu'il fonctionnait bien comme prévu,
• exécuter les tests unitaires avec NUnit.

Ce coup-ci, je me suis attaqué aux deux parties suivantes qui concernent la base de données :

• Creating the Database
• Building the Model

La création de la base de données s'est très bien passée. Le seul truc à noter c'est que la fenêtre "Server Explorer" s'appelle en fait "Database Explorer" sous VWD. Pour la création des tables, pas de problème non plus, si ce n'est que c'est un peu fastidieux. Je me demande si écrire un bête script SQL ne serait pas tout aussi pratique... En tout cas, pour l'ajout des données, ils auraient quand même pu donner un script tout prêt pour éviter d'avoir à tout ressaisir !

En ce qui concerne la réalisation du modèle, pas de problème non plus : bien que je sois sous VWD, tout se passe exactement comme décrit dans le tutoriel. Pour essayer de refaire les premiers essais d'intellisense tels qu'ils apparaissent dans le tutoriel, le plus simple est de se placer dans le source HomeController.cs après lui avoir ajouté la ligne "using NerdDinner.Models;" .

Pour le reste de la partie "Building the Model", je suis allé jusqu'au bout et j'ai tapé moi-même tout le code source proposé (à part les expressions régulières). Pour l'instant, je n'ai pas forcément tout assimilé en ce qui concerne LINQ to SQL et le pattern "Repository", mais c'est déjà ça de pris...

Et pour finir, j'ai décidé d'installer "SQL Server Management Studio". Après bien des péripéties, ça a enfin (et assez inexplicablement) réussi. Ca m'a permis de générer le script pour créer les deux tables Dinners et RSVP et pour initialiser leur contenu avec quelques données de tests.

Billet suivant dans la série : Troisième étape avec ASP.NET MVC