Principes de réalisation d'un DAC indépendant du SGBD en .NET 2.0

Une interface est en quelque sorte un contrat que doivent respecter les classes qui l'implémentent. L'objectif est de signaler qu'une classe doit implémenter des méthodes dont le nom est décrit dans le contrat. Ainsi, cette classe doit pouvoir effectuer certaines opérations, quelle que soit la manière de les réaliser. De plus, lors de la compilation, si une classe ne propose pas les fonctionnalités du « contrat » qu'elle est censée respecter, le compilateur renverra une erreur.

Prenons un exemple de la vie de tous les jours : certaines personnes sont des développeurs, d'autres des pilotes de formule1…

Quelles que soient notre occupation et notre formation, nous sommes tous des personnes. C'est pourquoi nous allons imaginer deux classes (Développeur et PiloteF1) qui doivent implémenter l'interface Personne. Par ailleurs, le Pilote de F1 est également un pilote, nous allons donc créer l'interface correspondant à sa fonction.

Les interfaces :

public interface Personne
{
    string Nom ;
    string Prénom ;
    …

    public char[2] getInitiales() ;
}

public interface Pilote
{

    public string getEcurie() ;
}

Les classes qui implémentent ces interfaces :

public class Développeur : Personne
{
    string Nom ;
    string Prénom ;
    HashTable LangagesConnus ;
    …
public char[2] getInitiales() ;
}

public class PiloteF1 : Personne, Pilote
{
    string Nom ;
    string Prénom ;
    string Ecurie;
    …
public char[2] getInitiales() ;
public string getEcurie() ;
}

On pourrait ainsi comparer une interface avec une classe abstraite pour laquelle aucune implémentation n'a été réalisée.

Pour réaliser notre couche d'accès aux données, il est nécessaire de passer par les interfaces. Effectivement, grâce à celles-ci nous connaissons les méthodes implémentées et nous sommes sûrs qu'elles sont bel et bien implémentées. C'est pourquoi il suffit (note de l'auteur: « si, si, il suffit… ») de créer une classe implémentant des méthodes statiques. Ces méthodes retournent des objets qui implémentent les interfaces. Pour savoir quel type d'objets doivent être renvoyés, nous passerons un paramètre aux différentes méthodes utilisées. Il existe bien entendu toute une série de moyens pour éviter de passer le paramètre à chaque méthode.

Certains se disent alors « Oui mais alors il faut passer de nouveau le code en revue pour y mettre le nom de l'objet désiré ». Évidemment, le problème serait le même, c'est pourquoi il est bon de mettre le nom dans le Web.Config dans le cadre d'asp.NET ou le App.config pour les WinForms.

Premier exemple: SqlConnection, OleDbConnection, OracleConnection et bien d'autres implémentent toute l'interface IDbConnection.

public class DbTemplate
{
    public static IDbConnection Connection(string sType)
    {
        IDbConnection cn=null;
        switch(sType)
        {
            case "SqlServer": cn=new System.Data.SqlClient.SqlConnection();
                break;
            case "Access": cn=new System.Data.OleDb.OleDbConnection();
                break;
            //...
        }
        return cn;
    }

    public static IDbCommand Command(string sType)
    {
        IDbCommand cmd=null;
        switch(sType)
        {
            case "SqlServer": cmd=new System.Data.SqlClient.SqlCommand();
                break;
            case "Access": cmd=new System.Data.OleDb.OleDbCommand();
                break;
            //...
        }
        return cmd;
    }
    …
}

On pourrait bien entendu ajouter d'autres méthodes renvoyant d'autres types d'objets. Il ne reste plus qu'à l'utiliser de la manière suivante :

IDbConnection Conn=DbTemplate.Connection("SqlServer");
IDbCommand Cmd=DbTemplate.Command("SqlServer");
IDataReader dr = DbTemplate.DataReader("SqlServer");

Cmd.Connection=Conn;
…
dr = Cmd.ExecuteReader() ;
…

Avec l'utilisation d'une clé dans le Web.Config (asp.NET) :

using System.Configuration ;
…

string DbType = ConfigurationSettings.AppSettings["DbType"] ;*

IDbConnection Conn=DbTemplate.Connection(DbType);
IDbCommand Cmd = DbTemplate.Command(DbType);
IDataReader dr = DbTemplate.DataReader(DbType);

Cmd.Connection=Conn;
…
dr = Cmd.ExecuteReader() ;
…

On notera que cette technique nécessite d'ajouter manuellement les différents providers dans la classe explicitée précédemment.

Certes, cette technique permet de mettre à jour uniquement la couche d'accès aux données, ce qui est plus efficace que de devoir mettre à jour tous les accès aux données.

Comme dans le cas de l'utilisation en .NET 1.1, les différents providers doivent implémenter des interfaces. C'est grâce à ces interfaces qu'il est possible de réaliser une telle organisation.

Le framework 2.0 inclut toute une série de nouvelles classes. Parmi celles-ci, deux nous intéressent tout particulièrement:

La première est DbProviderFactory. Il s'agit de la classe permettant de créer des objets Command, Connection ainsi que tous ceux qui s'y rapportent. Nous verrons cela dans le paragraphe consacré à l'utilisation de la classe DbProviderFactory.

Cette première classe est obtenue à l'aide d'une seconde, DbProviderFactories. Concrètement, c'est elle qui renvoie les objets des différents providers selon le paramètre qui lui est passé. C'est pourquoi les méthodes de cette classe sont statiques (comme l'étaient les méthodes de notre classe fabrique en 1.1).

La liste des providers disponibles est accessible dans le machine.config situé dans le répertoire $winapp$\Microsoft.NET\Framework\v2.0.50727\CONFIG.

En voici un extrait :

  <system.data>
    <DbProviderFactories>
      <add name="Odbc Data Provider" invariant="System.Data.Odbc" description=".Net _
          Framework Data Provider for Odbc" type="System.Data.Odbc.OdbcFactory, System.Data, _
          Version=2.0.0.0, Culture=neutral, PublicKeyToken=b77a5c561934e089" />
      <add name="OleDb Data Provider" invariant="System.Data.OleDb" description=".Net _
          Framework Data Provider for OleDb" type="System.Data.OleDb.OleDbFactory, System.Data, _
          Version=2.0.0.0, Culture=neutral, PublicKeyToken=b77a5c561934e089" />
      <add name="OracleClient Data Provider" invariant="System.Data.OracleClient" _
          description=".Net Framework Data Provider for Oracle" _
          type="System.Data.OracleClient.OracleClientFactory, System.Data.OracleClient, _
        Version=2.0.0.0, Culture=neutral, PublicKeyToken=b77a5c561934e089" />
      <add name="SqlClient Data Provider" invariant="System.Data.SqlClient" description=_
          ".Net Framework Data Provider for SqlServer" type="System.Data.SqlClient.SqlClientFactory, _
        System.Data, Version=2.0.0.0, Culture=neutral, PublicKeyToken=b77a5c561934e089" />
      <add name="SQL Server CE Data Provider" invariant="Microsoft.SqlServerCe.Client" description=_
          ".NET Framework Data Provider for Microsoft SQL Server 2005 Mobile Edition" _
        type="Microsoft.SqlServerCe.Client.SqlCeClientFactory, Microsoft.SqlServerCe.Client, _
        Version=9.0.242.0, Culture=neutral, PublicKeyToken=89845dcd8080cc91" />
    </DbProviderFactories>
  </system.data>

Bien entendu, il n'est pas nécessaire d'utiliser les API pour accéder aux valeurs du machine.config. La classe DbProviderFactories contient une méthode permettant de récupérer la liste des providers installés sur la machine, et ce, dans un DataTable. Vous pouvez ainsi afficher ces données dans un GridView par exemple ou encore effectuer des opérations dessus.

protected sub Page_Load()
{
    DataTable dt = DbProviderFactories.GetFactoryClasses();
    gridview.DataSource = dt;
    gridview.DataBind();
}

Ainsi, on peut manipuler le DataTable afin de vérifier l'existence d'un provider. Cette méthode le permet :

if (DbProviderFactories.GetFactoryClasses.Select("InvariantName='" + invariantName & "'").Length = 0)
    Response.Write(invariantName + "n'existe pas");

Comme on peut le voir dans l'exemple suivant, l'utilisation des classes DbProviderFactory et DbProviderFactories ressemble fortement à l'utilisation de notre objet DbTemplate en .NET 1.1.

IDataReader dbreader = null;

DbProviderFactory dbfactory =
   DbProviderFactories.GetFactory(
   ConfigurationSettings.AppSettings.Get("Provider"));

IDbConnection dbconn = dbfactory.CreateConnection();
dbconn.ConnectionString = ConfigurationSettings.AppSettings.Get("ConnectionString");
try
{
    dbconn.Open();
    IDbCommand dbcomm = dbconn.CreateCommand();
    dbcomm.Connection = dbconn;
    dbcomm.CommandText = "SELECT * FROM Clients";
    dbreader = dbcomm.ExecuteReader(CommandBehavior.CloseConnection);
    while (dbreader.Read())
    {
        Console.WriteLine("Client ID:{0}",
                          dbreader["ClientId"].ToString());
    }
}
finally
{
    if (dbreader != null) dbreader.Dispose();
}

Pour l'exemple précédent, il est nécessaire d'inclure deux namespaces :

using System.Data.Common;
using System.Configuration;

Même si cet objet n'est pas indispensable, il en est pour le moins intéressant. Il permet de diminuer le risque d'erreur lorsque vous écrivez votre ConnectionString.

Son utilisation est simple comme on peut le voir sur l'exemple suivant :

String connectionString = String.Empty;

//Get serverName from the user

SqlConnectionStringBuilder conStrbuilder = new SqlConnectionStringBuilder();
conStrbuilder.DataSource = serverName;
conStrbuilder.UserID = uid;
conStrbuilder.Password = pwd;

SqlConnection c = new SqlConnection (conStrbuilder.ConnectionString);

Toutes les propriétés ont une valeur par défaut. MinPoolSize est à 0 par exemple.

L'utilisation de cet objet permet de vérifier s’il n'y a pas d'erreurs lors de la compilation en lieu et place de les avoir à l'exécution.