I've been coding for ASP .NET with C# for a little while now - but there's something I have never been sure about.

For communicating between different .aspx forms, I've been storing Session state variables. Say for instance, one form loads up in a different way depending on which button the user clicks. Using my methods, I would save a session state variable that would tell that 2nd form how its supposed to load.

Am I doing this the way I should be? I've noticed lots of websites append variable information to the URL of the page using the '?'... like this message forum:

http://www.dbforums.com/newthread.ph...ad&forumid=192


I'm not sure what this is called or how it is implemented.

Any advice?

in ASP its response.querystring("element name")

session objects are in my opinion bad as they use server memory - I try to avoid them when not absoultly necessary...

check this link

http://www.w3schools.com/asp/asp_ref_request.asp

its for asp oldschool but there is .net stuff somewhere on the site

Much better to send modes via query string in URL (as
noted above) if you can.

Session state can be tricky to work with for these reasons:

1. IIS may start up more than one worker process,
called aspnet_wp.exe, and unless you set up your
Sessionstate XML block in web.config properly every
time a different aspnet_wp.exe process handles a
web request from the same user a new session will be
started, and you
will loose previous session state variables. This can
be avoided by using Microsoft's State Server that comes
with XP Pro, or saving state to MS SQL Server.

2. If you are eventually going to use a web farm, session state
must be managed across the entire garden, which means
you will have to use either State Server, SQL Server, or
something similar to save session state amongst all the
web boxes, or else every time the request gets routed to
a new box/process you will loose state.

3. Having to save and restore session state to State Server
or SQL server is much slower than if you just send your
form modes to the next web page via query string.

4. Finally, as previously noted above, Session state requires
memory, which is OK for small sites, but can quickly
add up for highly-trafficed sites.
Use Session state as a last resort, or when security
requires that you don't expose the information. Or
consider writing your state information to a fast DB.

I use MS State Server so my SessionState XML looks
like this:
<sessionState
mode="StateServer"
stateConnectionString="tcpip=xxx.xxx.xxx.xxx:42424 "
/>

I believe the default setup for sessionState is inProc,
which means if you have more than one aspnet_wp.exe
process running session state will eventually get hosed.