Using a session to persists an object

[Modica82]

Hi all,

I have just started a new job, and thought that i knew some stuff about .Net, but i am now seeing some code that has completly thrown me as to the benefits of it??

There is a start up page that loads, and within this start ups page load there is a routine that creates and instance of the main class for this application, and runs through a constructor that basically authenticates the user(not using the authentication model of .net). Then this object is persisted via session and is called on each page. Now even though in understand that i can be done, and i understand that its not a bad thing being able to persist an object via session state, but i dont really see the benefit of it???

From what i have learn using .Net for the last 12 months is that to persist user information its easier to use the built in classes to do so, and it is cleaner to instantiate and object as and when you need it.

The reason i am posting is i would like to here other peoples views on this, would be a good learning point for me.

Thanks,

Rob

 

[dalchri]

Although I do use FormAuthentication, the reason that I use Session state is because I need additional information about the user handy on each page. My website contains the user's orders and so on every page I need, at the least, his foreign key into the database.

I need to not just control access, but also to remember who I'm dealing with.

You may have no use for Session state if your website does not have information tailored to the individual user or if you are not collecting information from the user that spans several pages.

 

[obislavu]

When a request from a client is processed, that request passes through a series of objects named collectively as the HTTP pipeline.
These objects all need access to information about the reques, so an instance of the HttpContext class is created for each incoming request.
The HttpContext object is available throughout the HTTP pipeline to share information about the request.
The HttpContext object contains a large number of properties including:
-Request
-Response
-Application
-Cache
-Session
-Error
-User
-Handler
Application - allows access to the HttpApplicationState object for this request.
This object stores information relevant to entire ASP.NET application.Its methods include Add(), Get(), Set() which allow adding, accessing and modifying an object to the collection maintained by the HtppApplicationState object.

Cache - allows storing information for an ASP.NET application. The Cache object is similar to the Application object but it provides several extra features, for example, information stored in the Cache object can be set to expire in a specific period of time or to exist only as long as specific file exists.

Session - allows access to the HttpSessionState object for this request.
This object stores information solely about the client that made this request.
Like HttpApplicationState , it allows adding, reading and modifying arbitrary objects in a collecxtion.
As per your post, this object is especially important, so it will be described in more detail.

With ASP.NET the above properties of the HttpContext object are accessible directly through the Page class.
Since Page is the parent class for every .aspx page, the Request, Response , Session, Application, Error and Cache are readily accessible to every application.
Some of these objects are used to manage the application state.
Every request a client makes to an ASP.NET application causes the objects on the loaded page to be created, used and then destroyed.
First of all, the properties in Web controls are automatically saved by inserting their values into the Web pages sent to the user and then reading those values out again when the page is sent back. This is known as "state bag" and a developer can rely on the same approach to store any other information maintained by a particular page.
This inelegantly named mechanism allows an aplplication to store any values it whishes and have them restored when the user resubmits the .aspx. Like Web controls, the information in state bag is saved as fields in the page sent to the user.
This mechanism saves information only for a particular page in an ASP.NET application. What to do to save information used by several pages ? The answer is the Application object.
Information placed in the Application object is maintained on the server and made accessible to all pages in an application.
you can access the application object from any page:

<% Application("ArchiveStarted")= Now() %>

A page that wished to access the value of this variable:

<% response.Write(Application("ArchiveStarted")) %>

Alternatively, the Cache object can be used instead of the Application object.
Storing state in either of these objects has a problem: both are physically stored on a single machine.
If the ASP.NET application is deployed on several Web servers,each copy of the application will have its own instance of the Application and Cache objects.
The most common state management problem is maintaining per-client state: every page accessed by a client and only that client within an ASP.NET application should have easy access to this per-client state e.g. some way to store client-specific information across the life of a client session.
In ASP.NET , the Session object provides a way to do this.
One session object can exist for each active client. To figure out which client each request comes from, ASP.NET assigns each client a unique 120-bit session identifier that get stored in a cookie. The client then presents this cookie with each request it makes. User can turn off cookies if they wish but ASP.NET will embeed this identifier in the URL string returned to a user.
The traditional ASP Session object is bound to a single machine but this limitation doesn't exist in ASP.NET.
In ASP.NET , the Session object can still stored on just one machine and also in a separate Session State Store.
Here are the standards Session State Store provided by the .NET Framework:
-InProc - the Session object is stored in the same process as the application, much like the traditional ASP.
-StateServer- the Session object's state is stored in another process that can run locally or on another machine
-SQLServer - the Session object's state is stored on disk using SQL Server.
-Off - Session object is disabled.
Any state in the Session object is automatically destroyed when a client has not access the application for a configurable lenght of time.

Output caching.
==============
Do not confuse it with the Cache object that was refered above!
Output caching allows saving recently accessed results in memory. Caching repetitively accessed data is an efective way to speed up applications. Rather than doing the work required to recreate that data each time it is requested, the information can be read quicly from an in-memory cache and returned.
To use ASP.NET 's caching mechanism, an .aspx page can contain a directive like:

<%@ OutputCache Duration="180" VaryByParam="none" %>

Duration specifies in seconds how long the results of that page can be cached before the info must be recreated.
Requests that arrive for the same information within this period will have their responses returned immediately from the cache.
The VaryByParam attribute is set to none here but if desired it can be used to control exactly which results are cached.
The parameter this attribute refers to can be any named value contained in a a query string , which is the text following a "?" on a client request:

<%@ OutputCache Duration="180" VaryByParam="Company" %>

Assume further this page received two request with the followings query strings:

[URL unfurl="true"]http://www.ozone.com/finance.aspx?Company=BCE.TO[/URL]
[URL unfurl="true"]http://www.ozone.com/finance.aspx?Company=NT.TO[/URL]

Because output caching was instructed to vary by a parameter called "Company", the results of each request would be cached.
Requests to the finance.aspx page with Company id either BCE.TO or NT.To that are received within the 180 seconds window specified on the Duration attribute will return cached results.
The result is a more responsive application, especially if the same data is accessed over and over.
-obislavu-