Static et appli web

Bonjour,

J'aimerai quelques éclaircissements sur la manière dont se comporte un attribut statique dans une classe pendant la durée de vie d'une application web ASP.Net...

Voilà, mon expérience me vient surtout du PHP où, à chaque appel de page, tous les objets sont recréés et on a pas de persistance d'objet d'un appel au suivant. Donc j'ai un peu de mal avec les notions ASP.Net... Si j'ai une classe avec un attribut statique, j'ai cru comprendre qu'il était le même pour toute l'application (comprendre : tous les utilisateurs, tous les appels de pages tant qu'on ne relance pas l'appli), j'ai d'ailleurs fait un test et effectivement ça a bien l'air d'être ça...

Donc voici mon soucis (oué, j'y viens ^^)... Je voudrais initialiser un objet au début de l'appel à une page, accessible n'importe quand et n'importe où (donc aussi dans les différente classes) durant le traitement de cette page et uniquement cette page. Bref, que chaque page ait sa propre instance de l'objet, mais que je n'ai pas besoin de le ré-instancier à chaque fois que je l'utilise dans le traitement de la page.

J'espère que c'est clair :? Visiblement je ne peux pas utiliser un champ static (pour faire une classe type singleton) pour cela car l'objet sera instancié une fois pour toute et j'aurai toujours la même instance...

Comment puis-je faire pour me permettre au cours du traitement d'une même page, de n'initialiser qu'une seule fois un objet (à l'initialisation coûteuse mais variable - donc pas possible de le conserver pour toute l'appli) qui me serait accessible un peu partout dans les différentes classes que j'ai définies ?

J'espère que ce que je raconte est compréhensible :? Est-ce que vous auriez des idées ? *espoir*

Une variable private avec des accesseurs public devraient faire l'affaire non?

Merci pour ta réactivité ;)

Une variable private de la page tu veux dire ? J'y ai pensé, mais je vois deux soucis :

1) Est-ce que je peux avoir accès à la page courante dans une autre classe ? Via un HttContext.Current.QuelqueChose peut-être ? Pour pouvoir exploiter l'accesseur public pour tout mon traitement...

2) Mes pages ne sont pas en code behind (norme de dev internes obliges). J'ai une classe mère pour mes pages qui dérive de System.Web.UI.Page (mes pages en héritent par la directive inherits="MaPageDeBase") pour faire les traitements généraux. Je pourrais ajouter la variable et l'accesseur là, mais jusqu'à maintenant, je n'ai pas réussi, dans mes bloc <% ... %> à accéder à une méthode public de la classe mère de la page...

Citation:

---

Envoyé par Laewella

Mes pages ne sont pas en code behind (norme de dev internes obliges

---

Désolé pour le HS... Comment justifient-ils une telle norme?

@Neptune: Bah en fait, je crois que c'est parce que comme ça, ça ressemble à l'ASP et qu'avant tout était en ASP... Mais bon, je cherche pas trop à comprendre, je suis seulement presta et pas employé ici donc quand on me dit "ici, on fait comme ça", je réponds "ok, d'accord" et je me pose pas plus de question, sinon je m'en sortirais pas -_-

T'as pas un exemple de ce que tu souhaites faire?

Euh... alors par exemple, j'ai un objet qui représente l'utilisateur courant connecté au site. Mettons que je l'ai déclaré en privé avec un accesseur public CurrentUser dans ma page de base.
Je fais une page qui hérite de cette page de base, là en fait, je viens de retester, j'arrive à accéder à l'accesseur CurrentUser (mais VisualStudio n'a pas l'auto complétion si on a pas de code behind).
Par ailleurs, mettons que j'ai une classe qui pour une raison X, Y ou Z a besoin de l'utilisateur courant pour effectuer une action, mais cette classe, je vais pas l'appeler directement dans ma page, mais à travers d'autres classes, donc pas pratique de passer l'objet en paramètre.
Il faudrait donc que dans ma classe qui a besoin de l'objet CurrentUser, je puisse avoir accès à l'instance de ma page de base...

Est-ce plus clair ? :? Je sais que c'est pas toujours très simple ce que je raconte, désolée :oops:

Si c'est vraiment l'utilisateur dont tu as besoin (et pas un exemple fictif), je te suggère de jetter un oeil du coté du MemberShip d'asp.net.

Tu peux mettre en session et accéder à cette session dans tes classes.
Je vois pas trop comment ces classes pourraient avoir accès à ta page initiale

@neptune: non, non, c'est bien un utilisateur, mais c'est un objet maison.

@lutecefalco: oki, session donc, je vais peut-être voir de ce côté là ;)

Merci ;)

Citation:

---

Envoyé par Laewella

@neptune: non, non, c'est bien un utilisateur, mais c'est un objet maison.

---

OK, c'est génial alors ;-) Pourquoi ne pas épouser le fonctionnement interne d'ASP.NET, en l'enrichissant de ton objet maison? De cette façon, tu maintient possible l'utilisation de tous les controles ASP basé sur le Membership et en plus tu peux récupérer tes données propriétaires.

Bien sur, ca fait plus de travail, mais pour au final un meilleur résultat! Enfin, c'est toi qui voit ;-)

Citation:

---

Envoyé par neptune

Enfin, c'est toi qui voit ;-)

---

Bah justement... Non :D C'est pas moi qui vois, c'est la boîte où je suis en mission. On a pas toujours le choix en tant que développeur, je dirais, "en bas de l'échelle" et presta qui plus est.

En plus on utilise pas du tout le mécanisme d'authentification d'ASP.Net et les sessions et autres joyeusetés qui ne fonctionnent pas en architecture webfarm sont désactivées.

Mais bon, après discussion avec mon chef d'équipe, on a conclu que finalement, on avait besoin de ce mécanisme pour très peu d'objets que ceux-ci n'étaient pas très coûteux en instanciation grâce à des systèmes de cache très compliqués auxquels j'ai rien compris :D

Donc, merci ;)

N'empêche que je m'étonne qu'ASP.Net n'ait pas de moyen de faire facilement qu'une classe "singleton" s'initialise pour chaque nouveau traitement comme c'est le cas en PHP... Ça me paraît un concept assez utile...

Citation:

---

Envoyé par Laewella

les sessions et autres joyeusetés qui ne fonctionnent pas en architecture webfarm

---

Bah si !!!

Citation:

---

N'empêche que je m'étonne qu'ASP.Net n'ait pas de moyen de faire facilement qu'une classe "singleton" s'initialise pour chaque nouveau traitement comme c'est le cas en PHP... Ça me paraît un concept assez utile...

---

C'est pas le but d'un singleton de s'initialiser à chaque traitement, ou alors j'ai raté qqchose :)

Citation:

---

Envoyé par lutecefalco

Bah si !!!

---

bah sans doute pas tel quel sinon je pense pas qu'ils se serait fatigués autant pour faire des outils... Après, j'en sais rien ils ont peut-être une architecture particulière ou bien ils peuvent pas utiliser les concepts asp.net parce que c'est pas compatible avec leurs autres outils, j'en sais rien et j'avoue que je m'en fous :D Mais c'est comme ça que ça marche.

Citation:

---

Envoyé par lutecefalco

C'est pas le but d'un singleton de s'initialiser à chaque traitement, ou alors j'ai raté qqchose :)

---

Déjà j'ai mis "singleton" entre guillemets, c'est pas pour rien, c'était pour dire "une classe qui va me renvoyer une même instance et pas se réinitialiser à chaque fois". Et tout dépend de ce que l'on appel traitement. Moi je pense PHP parce que j'ai c'est avec ça que j'ai commencé à faire du web dynamique, et en PHP, chaque réponse à une requête séparée tourne dans une nouvelle instance de php, elles sont indépendantes sauf pour les objets mis en session explicitement, donc je peux avoir une classe avec un attribut statique qui me renverra la même instance tout au long de la réponse à un même traitement, mais qui aura une nouvelle instance pour chaque nouveau traitement... Mais visiblement, c'est une idée qui vous paraît totalement farfelue...
M'enfin, s'pas grave, finalement j'ai pas besoin de le faire.

Citation:

---

Envoyé par Laewella

Moi je pense PHP parce que j'ai c'est avec ça que j'ai commencé à faire du web dynamique, et en PHP, chaque réponse à une requête séparée tourne dans une nouvelle instance de php, elles sont indépendantes sauf pour les objets mis en session explicitement, donc je peux avoir une classe avec un attribut statique qui me renverra la même instance tout au long de la réponse à un même traitement, mais qui aura une nouvelle instance pour chaque nouveau traitement.

---

C'est le cas aussi en ASP.NET.

Citation:

---

Envoyé par lutecefalco

C'est le cas aussi en ASP.NET.

---

Alors je n'ai encore rien compris...

Cela dit, j'ai fait un test, avec une simple classe contenant une variable statique initialisée à 0 et incrémentée dans une méthode. Bah elle s'incrémente à chaque traitement qui appel cette méthode, par exemple, pour l'appel de la première page mettons qu'elle vaut 1, pour l'appel à la page suivante elle vaudra 2... Elle n'est donc pas réinitialisée...

Citation:

---

Envoyé par Laewella

Alors je n'ai encore rien compris...

Cela dit, j'ai fait un test, avec une simple classe contenant une variable statique initialisée à 0 et incrémentée dans une méthode. Bah elle s'incrémente à chaque traitement qui appel cette méthode, par exemple, pour l'appel de la première page mettons qu'elle vaut 1, pour l'appel à la page suivante elle vaudra 2... Elle n'est donc pas réinitialisée...

---

Oui, c'est une variable static quoi

Bah faudrait savoir... dans ce post :

Citation:

---

Envoyé par lutecefalco

C'est le cas aussi en ASP.NET.

---

tu me dis qu'en ASP.Net c'est pareil qu'en php et que la variable statique va avoir une nouvelle instance pour chaque traitement et maintenant tu me dis que c'est normal qu'elle ne soit pas réinitialisée ?
Qu'est-ce qui est juste ?

Ou alors tu veux me faire comprendre qu'un traitement c'est pas juste la réponse à une requête http (comme un php) mais que c'est plus vaste ?

J'avoue que je patauge un peu et que tes réponses m'embrouillent pas mal...

Pour résumer:
Une variable statique sera partagée par toute l'appli

Une variable au niveau de ta page sera instanciée à chaque chargement et gardera cette instance tout le long du traitement (de la réception de la requête jusqu'à la fin de la réponse)

C'est plus clair?

Oui, tout de suite, c'est plus clair ^^ Je crois qu'on s'est pas tout à fait bien compris dans les posts précédents ^^
Donc c'est bien ce que j'avais compris au début mais c'est pas ce que je voulais ^^

Merci pour le temps que t'as passé à m'expliquer ;)