Re: Best practice : storing objects in session-variables ?
- From: "John Timney \(MVP\)" <x_john@xxxxxxxxxxxxxxxxxxxx>
- Date: Thu, 31 Aug 2006 09:19:27 +0100
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)
<david@xxxxxxxxxx> wrote in message
news:fu3df2df30e1g446od2spphtijj3l8676o@xxxxxxxxxx
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 ?
.
- References:
- Prev by Date: Re: parameter from JScript to Asp.net
- Next by Date: Re: Unable to call COM dll's from application in ASP .NET 2.0 on IIS 6.0
- Previous by thread: Re: Best practice : storing objects in session-variables ?
- Next by thread: Re: Best practice : storing objects in session-variables ?
- Index(es):
Relevant Pages
|
