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
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
A voir également:
- EnterpriseLibrary 2005 vs EnterpriseLibrary 2006 the difference is obvious!
- Visual basic 2005 - Conseils pratiques -Visual Basic / VB.NET
- Is nothing vba ✓ - Forum Visual Basic
- Php protected vs private ✓ - Forum PHP
- Javafx vs swing - Forum Java
- Formation synchrone et asynchrone différence - Forum C / C++ / C++.NET
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
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
*/
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
*/
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
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
*/
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
*/
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
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 ;)
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 ;)