Zork[Yy]'s log

N-bases

Introduction

Parmi les avantages d'un ORM, nous retrouvons le support de multi-bases : la base devrait être un module abstrait, ainsi, le code ne devrait pas être développé et adapté selon la base sous-jacente. Les ORM, et notamment NHibernate, permettent de s'affranchir de cette partie (requêtes SQL, connexion, ...) et de rendre transparent la persistance des données en base.

NHibernate met en place des Dialects, qui grâce à eux, vous permettront, en utilisant l'API Criteria ou le langage HQL, de ne plus écrire de SQL. NH traduit votre requête objet dans le langage SQL de la base utilisée (qui est bien souvent non standard entre les différentes bases), ce qui abstrait totalement quelle base est utilisée.

Comment faire ?

NHibernate propose de charger une configuration selon le type de base utilisé. En changeant dynamiquement le fichier de configuration, on peut ainsi changer le fournisseur d'accès à la base.

Dans notre exemple, 3 configurations sont mises en place :

SQLite, contenu dans le fichier SQLite-nhihernate.config. Ce fichier précise quel Dialect utilisé, ici SQLite3, et divers paramètres, comme l'emplacement le base (connection_string) et la définition du modèle sous forme de fichier XML (MyDocumentRules : x.hbm.xml : les fichiers de mapping de nos entités) :

<?xml version="1.0" encoding="utf-8" ?>
<hibernate-configuration  xmlns="urn:nhibernate-configuration-2.2" >
    <session-factory name="mymedias">
        <property name="dialect">NHibernate.Dialect.SQLiteDialect</property>
        <property name="connection.provider">NHibernate.Connection.DriverConnectionProvider</property>
        <property name="connection.driver_class">NHibernate.Driver.SQLite20Driver</property>        
        <property name="connection.connection_string">Data Source=|DataDirectory|mydb.s3db;Version=3</property>
        <property name="connection.isolation">ReadCommitted</property>
        <property name="query.substitutions">true 1, false 0</property>
        <!-- HBM Mapping Files -->
        <mapping assembly="MyDocumentRules" />
    </session-factory>
</hibernate-configuration>

MySQL : idem mais pour MySQL :

<?xml version="1.0" encoding="utf-8" ?>
<hibernate-configuration  xmlns="urn:nhibernate-configuration-2.2" >
    <session-factory name="mymedias">
        <property name="dialect">NHibernate.Dialect.MySQLDialect</property>
        <property name="connection.provider">NHibernate.Connection.DriverConnectionProvider</property>
        <property name="connection.driver_class">NHibernate.Driver.MySqlDataDriver</property>
        <property name="connection.connection_string">Server=localhost;Database=mymedias;User ID=root;Password=mypasswd</property>
        <property name="query.substitutions">true 1, false 0</property>
        <!-- HBM Mapping Files -->
        <mapping assembly="MyDocumentRules" />
    </session-factory>
</hibernate-configuration>

MSSQL 2005 Express :

<?xml version="1.0" encoding="utf-8" ?>
<hibernate-configuration  xmlns="urn:nhibernate-configuration-2.2" >
    <session-factory name="mymedias">
        <property name="dialect">NHibernate.Dialect.MsSql2005Dialect</property>
        <property name="connection.provider">NHibernate.Connection.DriverConnectionProvider</property> 
        <property name="connection.driver_class">NHibernate.Driver.SqlClientDriver</property>
        <property name="connection.connection_string">Data Source=.\SQLEXPRESS;Pooling=true; Max Pool Size=2;persist security info=False;User Instance=True;AttachDBFilename=|DataDirectory|mymediasthec.mdf;Trusted_Connection=yes;</property>
        <property name="connection.isolation">ReadCommitted</property>
        <!--<property name="default_schema">
mymedias.dbo</property>-->
        <property name="query.substitutions">true 1, false 0</property>
        <!-- HBM Mapping Files -->
        <mapping assembly="MyDocumentRules" />
    </session-factory>
</hibernate-configuration>

Il nous reste plus qu'à charger (selon une clé positionnée dans l'application) le fichier de configuration que nous souhaitons utiliser, ce qui ressemblera à :

public class NHibernateSessionFactory
    {
        public static NHibernate.ISessionFactory GetSessionFactory(string configpath)
        {
            Configuration cfg = new Configuration();
            cfg.Configure(configpath);                        
            return cfg.BuildSessionFactory();
        }
    }
 
public class ContainerFactory
{
  public static NHibernate.ISessionFactory LaFactory
  {
     get 
     { 
         NHibernate.ISessionFactory laFactory =   NHibernateSessionFactory.GetSessionFactory(ConfigurationManager.AppSettings["ConfigDBPath"]);
         return laFactory;
     }
  }
}

Simple, portable et pratique.

Composition ou le one-to-one

Maintenant, nous allons ajouter une pochette à nos médias (couverture de livre, pochette de CD, ...). Cette relation entre un média et sa pochette s'effectue grâce à une composition : autrement dit, une pochette n'existe qu'au travers un média (un livre, un cd, ...), si le média n'existe plus, la pochette non plus (a contrario d'un auteur par exemple). Cela se représente par le diagramme suivant :

Sous NHibernate, cette relation s'effectue grâce à deux moyens, du côté du média (many-to-one) et du côté de la pochette (one-to-one).

Média, on aura la définition suivante dans le media.hbm.xml :

<many-to-one name="Pochette" class="MyConnector.Model.Pochette, MyConnector" column="pochette_id"
              not-null="false" lazy="false" cascade="all-delete-orphan"  />

J'ai mis à lazy="false" car lors de l'accès à une pochette, NH me ramène le proxy (constitué uniquement de l'id) et non l'objet, pas encore trouvé d'explications. cascade="all-delete-orphan" permettra de supprimer automatiquement la pochette dès que le média sera supprimé.

Pour la pochette :

<?xml version="1.0" encoding="utf-8" ?>
<hibernate-mapping xmlns="urn:nhibernate-mapping-2.2" auto-import="true" >
    <class name="MyConnector.Model.Pochette, MyConnector" table="pochettes">       
        <id name="Id" type="System.Int32">
          <generator class="foreign">
            <param name="property">Media</param>
          </generator>
        </id>
        <property name="Titre" column="title" not-null="false" type="System.String" access="property"/>
        <property name="Fichier" column="fileimage" not-null="true" type="System.String" access="property"/>
        <property name="SmallFichier" column="smallfile" not-null="false" type="System.String" access="property"/>
        <property name="Repertoire" column="dir" not-null="false" type="System.String" access="property"/>
        <property name="DateCreation" column="datecreation" not-null="true" type="System.DateTime" access="property"/>
 
        <one-to-one name="Media" class="MyConnector.Model.Media, MyConnector" constrained="true" />
    </class>
</hibernate-mapping>

La relation one-to-one pour la pochette (grâce à generator class="foreign") implique qu'une pochette aura le même id que le média, les 2 entités se partagent la même clé primaire.

Le constrained="true" permet d'induire une contrainte (et cela pétera votre appli. si elle n'est pas respectée...) et aussi selon Ayende (voir le commentaire de Sergey Koshcheyev) de construire une requête en inner join au lieu d'une left outer join, plus conforme pour ce cas.

On veillera à bien supprimer la pochette lors de la suppression d'un média (cascade delete), car cela constitue une contrainte d'intégrité pour NH (si le SGBD n'implémente pas les contraintes, on le fera donc du point du vue logiciel) : l'id du média correspond à l'id de la pochette, on pourra y trouver des avantages et des inconvénients à cette technique.

Conteneur IoC Castle Windsor

Il existe plusieurs conteneurs IoC : Spring, Windsor, ... Ce type de framework va nous servir à instancier des objets en s'appuyant sur des interfaces (abstraction) qu'auront implémentées des classes. Le framework s'intercale entre la couche de contrats (représentée par les interfaces) et l'implémentation, ce qui permettra d'introduire un découplage entre les couches : l'application Web ne connaît pas a priori quelle implémentation sera utilisée, elle n'utilisera que des implémentations d'interfaces (explicites).

L'avantage (ou inconvénients pour certains) du framework, c'est l'utilisation de fichiers (XML) pour décrire les implémentations à utiliser et l'injection d'objets le cas échéant dans les implémentations.

On veut remplacer l'injection que nous faisions à la main grâce à :

• IDALContainerFactory : création de la session NHibernate, obtention du container utilisé par l'ORM
• IDALContainer : container utilisé par l'ORM, qui pourrait changer (on utilise aussi un ORM maison : dsMap)
• IManagerControler : factory pour l'instanciation des contrôleurs

tout ceci va être remplacé par Windsor et son fichier de configuration CastleWindsorComponents.config :

<?xml version="1.0"?>
<configuration>
    <components>
        <!-- container ORM -->
        <component id="DALContainer"
                     type="MyDocumentRules.DALContainer, MyDocumentRules"
                     service="MyConnector.Interfaces.IDALContainer, MyConnector">
        </component>
 
        <!-- Managers / contrôleurs --> 
        <component id="mediasManager"
                   type="MyDocumentRules.MediasManager, MyDocumentRules"
                   service="MyConnector.Interfaces.IMediasManager, MyConnector"
                     lifestyle="transient">
            <!--lifestyle="custom"
            customLifestyleType="MyConnector.Util.HttpContextLifestyleManager, MyConnector">
-->
 
            <parameters>
                <container>${DALContainer}</container>
            </parameters>
        </component>
 
        <component id="auteursManager"
                     type="MyDocumentRules.AuteurManager, MyDocumentRules"
                     service="MyConnector.Interfaces.IAuteursManager, MyConnector"
                     lifestyle="transient">
          <parameters>
            <container>${DALContainer}</container>
          </parameters>
        </component>     
    </components>
</configuration>

Tous les objets à instancier sont décrits dans ce fichier sous la forme :

• d'un type du service (interface) : attribut service
• d'une implémentation à utiliser : attribut type
• d'un paramètre éventuel (à injecter ou à passer pour une valeur par exemple) lors de l'instanciation : les contrôleurs mediaManager et auteurManager ont besoin du contexte utilisé par l'ORM (qui reste abstrait au niveau de la couche présentation). Ce paramètre est dynamique et prendra la forme ${DALContainer}, Windsor utilisera le composant décrit dans le fichier, identifié par DALContainer. (component id="DALContainer")

Par défaut, les composants instanciés seront des singletons. Lors de l'utilisation d'un singleton, le client est vivement poussé à savoir ce qui se passe exactement dans l'objet (comment seront gérées les variables : sont-elles bien réinitialisées ou utilisées au bon endroit ?...). On peut jouer sur la forme d'instanciation grâce à l'attribut lifestyle, transient permet de créer un nouvel objet à chaque appel, plus rassurant pour le client de l'objet (ici le Web).

L'aide sur les possibilités de la configuration de Castle Windsor.

Ajoutons une classe utilitaire IoC qui encapsulera l'appel à Windsor :

namespace MyConnector.Util
{
    public static class IoC
    {
        private static IWindsorContainer _container = new WindsorContainer(new XmlInterpreter());
 
        public static T Resolve<T>()
        {
            return _container.Resolve<T>();
        }
 
        public static object Resolve(Type service)
        {
            return _container.Resolve(service);
        }
 
        public static void Reset()
        {
            if (_container != null)
            {
                _container.Dispose();
                _container = null;
            }
        }
    }
}

ainsi, un simple

IMediasManager mediaManager = IoC.Resolve<IMediasManager>())) as IMediasManager;

nous donnera accès au manager fraichement instancié.

On pourra mettre cela dans la classe utilitaire MyWebAppBasePage qu'utilisent les pages. Ici l'utilisation de HttpContext.Current.Items garantit qu'on utilisera le même objet pour toute la requête HTTP pour le même connecté, et non un thread éventuellement issu d'une autre requête HTTP (ASP.NET utilisant un pool de threads), ce qui peut provoquer des effets de bords (des propriétés initialisées pour le connecté X, puis transférées pour le connecté Y, on image le problème). Voir notamment ce très bon billet sur l'utilisation à éviter du ThreadStatic en environnement ASP.NET.

public class MyWebAppBasePage : Page
    {               
        #region Managers
 
        public IMediasManager mediaManager
        {
            get
            {                
                return (HttpContext.Current.Items["mediamgr"] ??
                    (HttpContext.Current.Items["mediamgr"] = IoC.Resolve<IMediasManager>())) as IMediasManager;                 
           }
        }        
 
        public IAuteursManager auteurManager
        {
            get
            {
                return (HttpContext.Current.Items["autmgr"] ??
                    (HttpContext.Current.Items["autmgr"] = IoC.Resolve<IAuteursManager>())) as IAuteursManager;
             }
        }        
 
        #endregion        
 
        public void delImagePochette(Media Media)
        {
            if (Media != null &&
                Media.Pochette != null)
            {
                int id = Media.Pochette.Id;
                string fic = string.Format("{0}\\{1}", Server.MapPath("/" + Media.Pochette.Repertoire), Media.Pochette.Fichier);
                if (File.Exists(fic))
                    File.Delete(fic);               
            }
        }
 
        protected override void OnInit(EventArgs e)
        {
            base.OnInit(e);
 
            Unload += new EventHandler(MyWebAppBasePage_Unload);    
        }
 
        void MyWebAppBasePage_Unload(object sender, EventArgs e)
        {
            IoC.Resolve<IDALContainer>().ClearWorkingContext();            
        }  
}

Sources

La démo est disponible sur Google code via SVN, à utiliser sous Visual Studio 2008, un F5 permettra de lancer l'application.

Prendre l'URL, un Checkout avec TortoiseSVN et c'est parti :

• La version 0.3 : http://mysampleapp.googlecode.com/s...

• Le trunk : http://mysampleapp.googlecode.com/s...

Je remercie mon jeune équipier AJN de m'avoir fait découvrir les choses suivantes :

• une méthode de validation de champs très sympa
• une pagination très simple à mettre en oeuvre