EnterpriseLibrary 2005 vs EnterpriseLibrary 2006 the difference is obvious! [Résolu]

Signaler
Messages postés
7
Date d'inscription
vendredi 23 mai 2003
Statut
Membre
Dernière intervention
10 août 2006
-
Messages postés
6351
Date d'inscription
samedi 1 juin 2002
Statut
Modérateur
Dernière intervention
2 août 2014
-
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

3 réponses

Messages postés
6351
Date d'inscription
samedi 1 juin 2002
Statut
Modérateur
Dernière intervention
2 août 2014
86
Ah bon, j'étais persuadé qu'il n'y avait pas eu de changement radical d'archi durant la vie de la version .Net 1.1...Mea culpa :-)
J'avoue ne pas avoir pousser les tests et je ne me souviens pas avoir vu d'article sur le sujet donc côté perf je ne pourrais pas te répondre.
Par contre si seule la partie SQL Server t'intéresse alors je pense que tu peux t'orienter vers une mise à ta sauce du DAAB de l'EntLib.
L'EntLib n'est pas forcément faite pour être utilisée tel quel :-)

/*
coq
MVP Visual C#
CoqBlog
*/
Messages postés
6351
Date d'inscription
samedi 1 juin 2002
Statut
Modérateur
Dernière intervention
2 août 2014
86
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
*/
Messages postés
7
Date d'inscription
vendredi 23 mai 2003
Statut
Membre
Dernière intervention
10 août 2006

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 ;)