Microsoft nous propose dans sa nouvelle version de ADO.NET la possibilité de mettre en place une certaine généricité dans le codage de nos applications u sein de la couche Data.
Bien sur pour ceux qui suivent, ils auront compris que je ne parle pas de la généricité = Template, mais bien des ajouts dans ADO.NET [ bon les autres peuvent sortir ]
L'ancienne monture des interfaces ( IDbConnection, IDbCommand, IDataReader etc ... ) censées nous apporter de la généricité dans le version 1.0 de ADO.NET ont été complétées, Microsoft a finit par comprendre que cela ne pouvait pas suffir, car ecrire du code propre et indépendant des providers et être quand même obliger d'instancer les classes spécifiques, cela ne pouvait pas convenir.

J'ai été de ceux, qui avait choisis dans un premier temps, de faire de l'instanciation dynamique, ( Reflection ) , j'avais aussi ajouter une notion d'alias comme en DELPHI [Merci Delphi].

Aujourd'hui je découvre que Microsoft a été dans ce sens, [ Delphi l'avait compris tres tôt ].
Dans la version de ADO.NET 2.0 on possède maintenant de nouvelles classes DbCommand, DbConnection, DbParameter, etc ... qui nous oblige plus à instancier les classes d'un provider afin d'obtenir l'interface générique, pour moi c'est une tres grande avancées de la part de ADO.NET.

public static DbProviderFactory GetFactoryAlias(ConnectionStringSettings p_connectionSettings)
    {
      return DbProviderFactories.GetFactory(p_connectionSettings.ProviderName);
    }

    /// <summary>
    /// Initialise une nouvelle instance de la classe DbConnection
    /// </summary>
    /// <param name="p_connectionSettings">Informations de connexion</param>
    /// <returns>nouvelle instance de la classe DbConnection</returns>
    public static DbConnection CreateConnection(ConnectionStringSettings p_connectionSettings)
    {
      DbConnection v_conn = null;
      v_conn = GetFactoryAlias(p_connectionSettings).CreateConnection();
      v_conn.ConnectionString = p_connectionSettings.ConnectionString;
      return v_conn;
    }

Il reste encore quelques points noirs, par exemple tous le monde sait que l'appel aux requêtes paramètrées, et aux procédures stockées diffèrent d'une base à l'autre :

• En Sql Server : on utilise des paramètres nommés et préfixés avec "@"
• En Oracle : on a aussi des paramètres nommées et preéfixés avec ":" ( non obligatoire )
• En Odbc & OleDb : on utilise des paramètres indicés

Il faudrait que le frameWork puisse prendre en compte cette gestion de paramètres afin de normaliser cela, un peu comme le faisait DELPHI, que toute cette cuisine soit masquée [Abstraction]

Bon je sais que des petits malins, me diront que la généricité en base de données n'existe pas, et je leur dirais que vous avez tout a fait raison, d'ailleurs la discussion ne porte pas la dessus, tout le monde sait tres bien qu'il y a des différences entre Oracle, SqlServer, Access etc ...

Mais l'idée c'est d'avoir une application capable de subir un changement de base en tres peu de temps, cad qu'on doit pouvoir se concentrer à ce qui est propre à la base de données lors de cette migration. Avoir un faible couplage [ je dis bien un faible couplage, et non un couplage faible] entre la coouche Data de mon application et la base de données utilisée.

Pour ceux qui souhaite avoir plus d'informations sur ces changements de ADO.NET 2.0