Utilité du Singleton pour des classes Manager et DAO ?

Bonjour,

Je suis confronté à des problèmes de performances sur un intranet que je maintiens et je me posais des questions quant à l'utilisation des singletons !
Suite à des gros problèmes de connexion, j'ai déjà viré le Singleton qui permettait d'accéder à la base, une bonne chose de faite :o

Je voudrais votre avis concernant l'architecture retenue pour cet intranet, en gros, ça donne ça :

Page ASPX -> Instance Classe Manager -> Instance Classe DAO -> Classe SQL en static qui effectue la requête !

Les problèmes de perfs peuvent-ils venir des Singleton Manager et DAO ?
En effet si 2 utilisateurs décident d'accéder à la même page, ne va-t-il pas y avoir un accès séquentiel et donc un ralentissement de l'appli ?

Merci d'avance pour votre aide :ccool:

Pour préciser un peu, voici à quoi ressemble les classes Manager et DAO, avec une classe simple :o

Code:

---

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27

public class ProjetManager { private static ProjetManager s_Instance; private static object s_InstanceLocker = new object();   // Singleton new public static ProjetManager Instance { get { lock (s_InstanceLocker) { if (s_Instance == null) { s_Instance = new ProjetManager(); } return s_Instance; } } }   public DataTable Get_All_Projets() { return ProjetsDAO.Instance.Get_All_Projets(); } }

---

Code:

---

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41

public class ProjetsDAO { private static ProjetsDAO s_Instance; private static object s_InstanceLocker = new object();   public static ProjetsDAO Instance { get { lock (s_InstanceLocker) { if (s_Instance == null) { s_Instance = new ProjetsDAO(); } return s_Instance; } } }   public DataTable Get_All_Projets() { return Get_All_Projets_FromDB(); }   private DataTable Get_All_Projets_FromDB() { DataTable dt = null; try { dt = Sql.RunSPReturnDT("PROC_GET_ALL_PROJETS"); } catch (Exception ex) { ; }   return dt; } }

---

Mes soucis de perfs peuvent-ils donc venir des locks des Singletons ?
Sachant que CHAQUE procédure stockée est exécutée suivant le même schéma à travers les différentes classes Manager + DAO !

D'expérience, je dirais que le singleton a rarement une utilité a part quand on veut concilier héritage et "static".
La plupart du temps j'utilise une classe statique et une pile de contextes (si j'ai besoin de gérer des données supplémentaires modifiables). Tous les appelants appellent le contexte par défaut sauf certains qui utilisent un contexte propre.
En implémentant IDisposable de manière futée on peut écrire:

Code:

---

1 2 3 4

using (var context = new MyContext()) { MyStaticClass.Execute(blabla); }

---

ou pour utiliser le contexte par défaut, simplement:

Code:

---

MyStaticClass.Execute(blabla);

---

Désolé mais je n'ai pas compris ton message !
Je n'ai jamais utilisé d'interface et ne dois pas avoir un niveau de connaissance suffisant pour coder de la sorte :aie:

Avant de transformer mes Singletons en classes static, penses-tu que les lock des Singletons puissent être la source de problèmes de perf ?

Si 2 utilisateurs essaient d'accéder à la même page à 1 seconde d'intervalle, le premier ne va-t-il pas bloquer le second avec ces histoires de lock ?

Il me semble que faire ceci est mieux

Code:

---

1 2 3 4 5 6 7 8 9

if (s_Instance == null) { lock (s_InstanceLocker) { s_Instance = new ProjetManager(); } } return s_Instance; }

---

car sinon tu lock Instance à chaque fois que tu y accèdes même si je ne pense pas que se soit le temps d'acces à ta variable qui ralenti énormement le truc.

Je ne vois pas pourquoi le singleton va ralentir ton programme.

Le mieux serait peut-être de mettre des traces pour voir ce qui prend du temps.
Voir combien de temps prend le select

Merci pour ta réponse !

Tout le monde confirme que ce genre de code ne peut pas être à priori à l'origine de temps de réponse affreux ? :aie: