EnterpriseLibrary 2005 vs EnterpriseLibrary 2006 the difference is obvious!

Résolu
cs_morisse Messages postés 7 Date d'inscription vendredi 23 mai 2003 Statut Membre Dernière intervention 10 août 2006 - 6 août 2006 à 14:57
cs_coq Messages postés 6349 Date d'inscription samedi 1 juin 2002 Statut Membre Dernière intervention 2 août 2014 - 6 août 2006 à 23:30
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

cs_coq Messages postés 6349 Date d'inscription samedi 1 juin 2002 Statut Membre Dernière intervention 2 août 2014 101
6 août 2006 à 23:30
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
*/
3
cs_coq Messages postés 6349 Date d'inscription samedi 1 juin 2002 Statut Membre Dernière intervention 2 août 2014 101
6 août 2006 à 18:16
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
*/
0
cs_morisse Messages postés 7 Date d'inscription vendredi 23 mai 2003 Statut Membre Dernière intervention 10 août 2006
6 août 2006 à 23:06
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 ;)
0
Rejoignez-nous