Discussion :

[jowsuket]

Bonjour,

J'ai récemment appris le concept de singleton et j'en ai déjà utilisé dans des application type WinForm.
J'explique ce que j'entends par singleton avec l'exemple suivant :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
public class MaClasse
{
    private static MaClasse instance_;
 
    public static MaClasse GetInstance()
    {
        if (instance_ == null)
        {
            instance_ = new MaClasse();
        }
        return instance_;
    }
 
    private MaClasse()
    {
 
    }
}

Le but étant d'obtenir (ici via la méthode GetInstance()) une instance d'un objet qui restera la même pendant toute la durée de l'exécution du programme.
Dans les applications Windows que j'ai développé, pas de problème car il n'y avait qu'un utilisateur par application.
Or maintenant je travaille sur un site WebForm et quand j'utilise ce type de code, l'instance en question est la même pour tous les utilisateurs... Cette réaction était prévisible mais je me demandais si il existait une technique pour conserver en mémoire une instance d'objet par utilisateur.
Sachant, pour compliquer ma petite affaire, que l'objet en question n'est pas dans le dossier App_code du site mais dans une bibliothèque de classes référencée par le site (un .dll que je compile et place dans /Bin)

A vous de me dire si ce que je souhaite relève de la science fiction

[galpha]

Il est vrai que tu ne peux pas utiliser de Singleton de la même façon qu'un application WinForms.

Personnellement, je l'implémente de cette façon:

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
8
9
10
11
12
13
14
 
public class Database
{
    public static Database Current
    {
        get
        {
            return (HttpContext.Current.Items["Database"] ??
                (HttpContext.Current.Items["Database"] = 
                new Database())) as Database;
 
        }
    }
}

Utilise le HttpContext .

[Philippe Vialatte]

Je vais peut-etre repondre a cote de ta question, mais qu'est-ce qui te motive dans l'utilisation d'un singleton en webforms ?

Dans 80% des cas, le singleton est utilisé à mauvais escient, voire provoque des bugs (locks, pb de conditions bloquantes etc...), et peut etre avantageusement remplacé par un objet deja existant du framework (utiliser la session peut etre une solution, meme si le code de galpha me fait un peu peur...)

[jowsuket]

L'objectif est de maintenir un objet dataSet en vie pour un utilisateur entre deux chargement de page.
Si mon objet DataSet était crée dans mon site web même, je l'aurrai stocké dans :
- Une Session (HttpContext.Current.Session)
- Ou encore plus fou, dans un ViewState (bien que ça doit être désastreux pour la bande passante de stocker autant d'informations sur la page du client...

Mais ma solution VB a été faite de façon très scolaire :
- Un projet de site web
- Un projet librairie de classes pour le modele (les classes métier)
- Un projet librairie de classes qui contient mon dataSet Typé
- Un projet librairie de classes pour ma dal qui contient des classes avec des méthodes statiques qui tapent dans le dataset pour fournir/mettre à jour en base les classes métiers.

[Philippe Vialatte]

L'objectif est de maintenir un objet dataSet en vie pour un utilisateur entre deux chargement de page.

...a ne pas faire

Le probleme du dataset, c'est que le conserver en memeoire risque de te faire peterla memoire a moyen terme.

Les datasets sont generalement de gros objets, et le fait de les stocker en memoire risque de faire planter le site en fonction de la charge.

Si tu as des données à stocker d'un appel a l'autre, il vaut mieux eventuellement stocker tes objets metiers en session, le mieux etant de ne conserver que l'id de ton objet

[jowsuket]

D'accord, merci pour l'information.
Mais ceci m'amène à la question suivante :
Pont-on exploiter de façon efficace un DataSet si on ne peut pas le garder en mémoire?
Un dataset par définition permet de stocker temporairement des enregistrements (avec la méthode fill) et de les mettre à jour (avec la méthode update) en vérifiant la concurrence. Si on ne peut pas stocker le DataSet une fois charger, ça veut dire que pour faire un update depuis une page web on doit au même moment :
- Le recharger
- Le modifier
- Déclencher la mise à jour (update du/des dataAdapter)
Du coup on obtient l'équivalent d'une solution en mode connecté... Y'a-t-il un intéret d'utiliser un DataSet?
Enfin je crois que je m'éloigne quelque peu du topic de mon post initial.

[rad_hass]

Même si Philippe ne l'a pas dit (il n'en pense pas moins je crois) les dataset c'est mal ... Très mal ...

[Philippe Vialatte]

Même si Philippe ne l'a pas dit (il n'en pense pas moins je crois) les dataset c'est mal ... Très mal ...

pas faux

Un dataset par définition permet de stocker temporairement des enregistrements (avec la méthode fill) et de les mettre à jour (avec la méthode update) en vérifiant la concurrence. Si on ne peut pas stocker le DataSet une fois charger, ça veut dire que pour faire un update depuis une page web on doit au même moment :
- Le recharger
- Le modifier
- Déclencher la mise à jour (update du/des dataAdapter)
Du coup on obtient l'équivalent d'une solution en mode connecté... Y'a-t-il un intéret d'utiliser un DataSet?

Le truc a voir, c'est que le dataset (avec ses fill et compagnie) a quand meme ete principalement pense pour le developpement d'applications de bureautique (historiquement, le framework etait prevu pour du developpement de winforms, les webforms ont ete ajoutees un peu de facon "guerilla" alors que le projet etait deja aps mal avance), dans lesquels tu as des cas d'utilisations valide pour conserver une quantite de donnees importantes en memoire, et la syncroniser periodiquement avec ta bdd.

En web, on est de toute facon sur un mode asynchrone, et on ne maitrise absolument pas des donnees comme la frequence a laquelle les donnees sont rafraichies, ou meme le fait qu'un client refasse ou pas une requete

Donc, se baser sur un dataset pour ca...c'est un peu utiliser un elephant pour chasser les mouches...c'est lourd, c'est encombrant, mais ca peut marcher

A la limite, utiliser un dataset pour "transporter" les donnees de ta bdd a ton ecran, ok, mais dans le sens inverse, le cout du dataset est souvent trop important, alors autant gerer les mises a jour autrement

[jowsuket]

Merci pour ces informations.

Je vais laisser de coté l'idée DataSet dans mon développement web.

[Philippe Vialatte]

Je vais laisser de coté l'idée DataSet dans mon développement web.

Yes, un de plus...

Un par un, je les ferais se repentir de leur adoration malsaine du démon DataSet...


Euh...non, j'ai rien dis