Best practice : storing objects in session-variables ?

[david]

I have a class with some business-logic and with every roundtrip, I need
an instance of this class, so I have to create it, every time again.

That doesn't seem very efficient. I thought it would be 'better' to store
an instance of this class in a session-variable, so it's available all the time
and needs to be instanced only once.

Is this, generally speaking, a good idea, storing objects in session-variables ?
Do you guys ever use this 'technique' ?

Or, in other words, what's the 'best practice' when one wants to
use objects (and/or want to do OO-programming) in ASP.Net ?

Who can give me some insights ?

 

[Laurent Bugnion]

Hi,

I have a class with some business-logic and with every roundtrip, I need
an instance of this class, so I have to create it, every time again.

That doesn't seem very efficient. I thought it would be 'better' to store
an instance of this class in a session-variable, so it's available all the time
and needs to be instanced only once.

Is this, generally speaking, a good idea, storing objects in session-variables ?
Do you guys ever use this 'technique' ?

Or, in other words, what's the 'best practice' when one wants to
use objects (and/or want to do OO-programming) in ASP.Net ?

Who can give me some insights ?

Generally speaking, the web paradigm is to be stateless. The server
should, in theory, be able to evaluate the current state of the system
on each request.

However, this is hardly possible for web applications often for
performance reasons (to avoid creating classes on every roundtrip, to
avoid fetching data from a DB too often, to avoid having to send
information back and forth...).

IMHO, your role as developer is to evaluate each scenario and to decide
if it makes sense to store things in the Session (or using other
mechanisms, for example static classes, the Application object, files,
etc...) to persist state, or if a more "webby" approach is possible.

Note however that stateless is, in my experience, easier to implement.
As soon as you have a state in your application, then the test cases get
much more complicated.

HTH,
Laurent

 

[offwhite]

I find that you want to use Session as infrequently as possible because
it can take up a lot of memory on a higher traffic website. Instead
try to make use of System.Web.Cache.

When you do this a business object, you may have criteria you can use
to identify this business object. Say it is a Product which has a
unique ID. You can access with the following code which will save you
from hitting the database for every request.

Besides, placing it in the session only makes it available to that
single user while the cache is available to everyone so it will help a
high traffic website.

public Product FindProduct(string productId)
{
Cache cache = HttpRuntime.Cache;

string cacheKey = "Product-" + productId;
Product product = cache[cacheKey] as Product;

if (product == null)
{
... code to load product from domain ...


... add the product to the cache using cacheKey ...
}

return product;
}

With the default cache settings you should see some nice performance
improvments. And also keep in mind that you can use System.Web.Caching
outside of an ASP.NET runtime.

http://www.hanselman.com/blog/CommentView.aspx?guid=5d482643-a44e-4d67-944b-f08c75183cc1

Here are a few related articles on the topic which I found useful.

http://msdn2.microsoft.com/en-us/library/ms178597.aspx
http://msdn2.microsoft.com/en-us/library/ms178604.aspx
http://msdn2.microsoft.com/en-us/library/ms164606.aspx

CacheItemPriority
http://msdn2.microsoft.com/en-us/lib...mpriority.aspx

CacheItemRemovedCallback
http://msdn2.microsoft.com/en-us/lib...dcallback.aspx

 

[John Timney \(MVP\)]

Whether it is or is not good practice to instanciate the object each time
often depends on what the performance impact might be, and whether holding
state of an object may cause other issues. DB connections for example
should always try to connect, extract/update data and disconnect, so if your
class is holding connections open it then storing it in the session is not a
good idea as you could in theory run out of available connections and
pooling is less efficient.

Also, on a heavy traffic site, adding memory hungry objects to session can
grind your server to its knees. So, you will need to test how your
application performs with objects in session, and without them - and make a
design decision.

Regards

John Timney (MVP)

 

[Hans Kesting]

I have a class with some business-logic and with every roundtrip, I need

an instance of this class, so I have to create it, every time again.

That doesn't seem very efficient. I thought it would be 'better' to store
an instance of this class in a session-variable, so it's available all the
time and needs to be instanced only once.

Is this, generally speaking, a good idea, storing objects in
session-variables ? Do you guys ever use this 'technique' ?

Or, in other words, what's the 'best practice' when one wants to
use objects (and/or want to do OO-programming) in ASP.Net ?

Who can give me some insights ?

It's not a problem to store "objects" (as opposed to value-types like
int) into Session. You could even say it's better to store objects than
value-types, because those value-types need "boxing" and "unboxing".

If the object is specific to a user, then you can use Session. If it's
the same for all users then consider Cache: then you can use a single
instance everywhere, instead of multiple identical copies.

Hans Kesting

 

[Mark Rae]

If the object is specific to a user, then you can use Session. If it's the
same for all users then consider Cache: then you can use a single instance
everywhere, instead of multiple identical copies.

How do people feel about Cache vs Application for storage of "singleton"
type stuff...?

 

[david]

I have a class with some business-logic and with every roundtrip, I need

an instance of this class, so I have to create it, every time again.

That doesn't seem very efficient. I thought it would be 'better' to store
an instance of this class in a session-variable, so it's available all the time
and needs to be instanced only once.

Is this, generally speaking, a good idea, storing objects in session-variables ?
Do you guys ever use this 'technique' ?

Or, in other words, what's the 'best practice' when one wants to
use objects (and/or want to do OO-programming) in ASP.Net ?

Who can give me some insights ?

Everybody thanks for your responses.

 

[sloan]

I have a more formalized "web object holder" ... that I use.
Its basically a session object via a singleton.

See
http://sholliday.spaces.live.com/ 10/24/2005

Use the cache with care. I do it alot, but I don't put huge objects in
there.

But when I have a webpage, where a user gets a list of data... and then they
want to resort it ...
I put the backend (strong) DataSet into this object cacher thing.

With my object cacher, remember to always use .Remove(key) if you only need
it once. Indexer will leave it in the cache.

...

 

[byapti]

I have a more formalized "web object holder" ... that I use.
Its basically a session object via a singleton.

See
http://sholliday.spaces.live.com/ 10/24/2005

Use the cache with care. I do it alot, but I don't put huge objects in
there.

But when I have a webpage, where a user gets a list of data... and then they
want to resort it ...
I put the backend (strong) DataSet into this object cacher thing.

With my object cacher, remember to always use .Remove(key) if you only need
it once. Indexer will leave it in the cache.

..

 

[byapti]

Hi,
One can go through an article on "Boxing & Unboxing in .NET" at
http://aspalliance.com/986_Boxing_and_Unboxing_in_NET