salut,  
je viens de faire un test qui vise à passer des données d'une page A à une page B (page aspx).
 
dans ma page a.aspx j'ai le code suivant

 
Dans le page load de la page A j' instancie la class transfertDonnee et je l'enregistre dans ma variable de session

 
Dans ma page B je récupere le pointeur de ma class, je le cast et j'affiche les données

 
Cette methode fonctionne bien, par contre je n'ai pas trouver de reference à cette maniere de passer des parametres sur le net.
 
Avis au spécialiste, est ce bien de proceder de cette manière? il y t'il des désavantage majeurs?
merci..

Pas besoin d'être un spécialiste, c'est un peu la base de la programmation ASP.Net.
Un inconvénient majeur ?
Bein.. .imagine que je tape l'URL de la page 2 dans mon navigateur, sans passer par la page 1.
Que se passe-t-il ?    
 
La session c'est bien pour partager des donnée dans un application.
Mais pour passer des données d'une page à l'autre, je recommande la querystring.

Bon petit récapitulatif, le passage de paramètre d'une page A à une page B peut se faire de plusieurs manières différentes:
1° soit par cross post back (interface et compagnie)
2° soit par session
3° soit par querystring
4° soit par formulaire avec server.transfer
 
Dans tout les cas de figure quand tu attaques directement la page B tu ne recuperas pas les données que tu passes depuis la page A.
 
La query pour passer des données d'une page à une autre c'est le mal, je me vois bien annoncer à mon chef que l'application à été piraté parce que j'ai passé un numéro de compte par querystring.. Éventuellement tu peux passer des données de paramétrage par query, mais pas de données métier (c'est un peu la base).
 
Contrairement à ce que tu pense le fait de sessionner une classe (pas une variable simple j'entend) n'est pas très rependu en asp.net, en tout cas à ma connaissance. D’ou ma question.

pas besoin d'être un expert pour savoir qu'il ne faut pas mettre en session d'objets. suffit de lire la doc, toutes les pages de la MSDN disent qu'il ne faut surtout pas le faire. (même celles qui parlent pas de C# ni d'ASP)

ce que je veux savoir c'est pourquoi? (fuite de memoire, volatilité,possibilité d'ecrasement intenpestive par une autre page).
si t'as un vrai lien qui l'explique je suis prenneur..
 
ps: l'argument "tout le monde sait bien qu'il faut pas le faire" c'est vraiment middle...

1/ charge mémoire : un objet peut rapidement grossir en taille, et la multiplication de leurs instances est très dangereuse
2/ modèle de stockage des sessions : un objet stocké en session est "hashé" afin d'être stocké dans une zone de stockage (SQL Server par exemple). cette action s'avère coûteuse en CPU, et peut provoquer un comportement aléatoire de l'objet
3/ problème de locks sur des ressources mal releasés : si l'objet travail avec un stream fichier par exemple, il peut le locker, et ne pas le relâcher comme désiré
4/ effectivement, une autre page peut venir empièter dessus. deplus, si une autre action dans la même session utilisateur est effectuée, tu peux rapidement avoir des problèmes quasi impossibles à détecter à cause de multi-threading non prévu (page1 lance un traîtement A se basant sur une propriété B, alors qu'une page 2, au même moment, dans la même session, va modifier la valeur de B : boum assuré, sans aucun moyen de comprendre ce qu'il s'est passé
5/ tu ne maîtrises pas quand la session expire, et encore moins sa façon d'expirer. ainsi, ce n'est pas parce qu'une session arrive à expiration que les objets qu'elle contient vont être détruits. et lorsqu'il seront détruits, tu ne peux pas être certain que le destructeur sera appelé correctement
 
ps : ce n'est pas seulement un argument "tout le monde le sait", c'est aussi un problème d'expérience. je suis intervenu il y a deux mois sur un site afin de résoudre un problème lié au stockage d'un objet de connection SQL en session : au bout de quelques heures, le serveur Oracle s'effondrait faisant planter l'ERP qui travaillait dessus

merci pour ta réponse détaillée    
je ne placais pas ma question spécifiquement au niveau de la performance de l'objet session, mais plutot sur le faite de sessionner des données dans une class..
imaginont que tu dois passer 3 champs d'un formulaire par session.
- nom
- prenom  
- age
quelle est la difference entre faire 3 variables de session distinctes et une variable de session contenant une class qui regroupe ces trois valeurs?

plutôt que d'utiliser une class dans ce cas, utiliser une structure (struct).
l'intérêt d'une structure, c'est que c'est géré comme un type de valeur, même si c'est instanciable et que ça peut gérer des méthodes.
 
sinon, très franchement, évite les variables de session au maximum. c'est le meilleur moyen d'avoir un comportement instable de l'application, si par exemple le gars s'amuse à jouer entre le bouton back, next et ses favoris : le gars peut arriver sur une page avec un état incohérent de ses sessions, et provoquer une série d'erreurs parfois très difficile à isoler et éviter. j'ai déjà eu à faire à ce type de problème sur un site ecommerce, où la collecte d'informations de l'utilisateur se faisait en plusieurs étapes : une partie lors de l'inscription, et une partie lors de la commande. très rapidement, à force d'ajouter des cas spécifiques et autres joyeusetés, on est arrivé à la possibilité pour un gars de passer commande sur une adresse qu'il venait juste de modifier, ou mélanger l'adresse de livraison avec celle de facturation : tu déroulais le site normalement, pas de souci. le gars faisait back et next afin de faire des copier/coller de valeurs qu'il venait de saisir dans un autre formulaire, et ça partait en vrille total... quand le gars se retrouve avec un 38 tonnes transportant un équipement d'IRM devant le cabinet de son comptable, ça la fout mal.
 
use et abuse de la base de données. tu remplis au fur et à mesure de leur saisie des infos dans la base, et tu identifies le gars simplement avec son session id, ou son login/pass lorsqu'il est connu. une simple procédure de nettoyage peut venir détruire les valeurs anonymes saisie il y a plus d'une heure par exemple.
 
ça fait des années que je ne stocke plus rien en session (je désactive systématiquement la gestion des sessions tel que c'est recommandé dans les whitepaper d'installation, optimisation et sécurisation de IIS, du coup je ne suis pas tenté de les utiliser ), et lorsque c'est bien réfléchit, ça n'ouvre pas la moindre faille de sécurité.

le truc a savoir qunad mm sur les variables de session, c'est que les objets qu'on y met doivent être sérializable. Donc implémenter l'interface ISERIALIZABLE. Sans ça, c'est clair que ça peut provoquer des droles de comportements

ok merci de vos reponses..
 
j'ai trouvé un lien sympa qui récapitule un peu tout ca, je vous le colle
 
http://msdn2.microsoft.com/fr-fr/l [...] S.80).aspx