EnterpriseLibrary 2005 vs EnterpriseLibrary 2006 the difference is obvious!

Bonjour a tous,
Je suis en train de reconvertir du code ecrit avec l'EnterpriseLibrary january 2005
avec la nouvelle de 2006.
Petit example before/after

01/2005
DataSet ds = SqlHelper.ExecuteDataset(ConString, CommandType.StoredProcedure, "MySPName", new SqlParameter("@ParamName", ParamValue);

01/2006
Database db = DatabaseFactory.CreateDatabase();
DbCommand dbCommand = db.GetSqlStringCommand("MySPName");
dbCommand.CommandType = CommandType.StoredProcedure;
db.AddInParameter(dbCommand, "ParamName", DbType.String, ParamValue);
DataSet ds = db.ExecuteDataSet(dbCommand);

5 lignes a ecrire au lieu de 1 avant! Y'a pas moyen de faire plus simple...
Faut il ecrire son propre wrapper pour diminuer tout ca?

Merci pour vos commentaires

Salut,

A ma connaissance ce que tu appelles EntLib de janvier 2005 n'a pas l'air de l'être (à ma connaissance le DAAB de l'EntLib y utilisait déjà Factory). Il s'agit plutôt du DAAB existant avant la naissance de l'EntLib non ?

Sinon pour le côté réduction tu peux commencer par utiliser GetStoredProcCommand au lieu de GetSqlStringCommand, ça te permettra de supprimer la ligne suivante je pense.
En dehors de ça non mais ça ne me choque pas trop, j'ai tendance à préférer le côté changement de DB sans recompiler par rapport à l'économie de qq lignes ;-)


/*
coq
MVP Visual C#
CoqBlog
*/

Exact celle de janvier 2005 est la premiere qui avait un gros bug que j'ai eu la joie de decouvrir :), mais qui n'utilise pas de factory mais un wrapper (SqlHelper).
Deja un bon point avec GetStoredProcCommand au lieu de GetSqlStringCommand :).
Autrement y'a t'il un moyen d'ajouter les arguments sans avoir a les 'pseudo caster' du style addParameter("@ParamName", strParamValue) au lieu de addParameter("ParamName", DbType.String, strParamValue)?

Mise a part la violation de l'architecture 3 1/3, y'a t'il un gain de performance en utilisant SqlDatabase au lieu de Database??? J' ai googlé et je n'ai pas vu de litterature notable sur ce point si certains ont des pointeurs sur d'eventuelles documents a ce sujet.
Certe SqlDatabase herite de Database et prend en compte les specificites de SQL Server (@ nommage des valeurs par. ex.), mais qu'en est il avec les performances et 'facilites d'ecriture'.
Je ne travaillerai qu'avec SQL Server, mais si il n'y a aucunes differences autant respecter les couches.
Perso je preferes un code dedie et efficace, qu'un code 'passe-partout' mais non optimise... donc le changement de DB sans recompil ne m'interresse pas...pour l'appli que je developpe ;)