Dataset In Session Variable

  • Thread starter Thread starter Miro
  • Start date Start date
M

Miro

Quick question...

I was watching a tutorial video and in that example they created a DataSet -
filled it with some data (small amount of data).
Then they stored it to a session variable.

On postbacks they just kept using that dataset filled data for some
comparisons.

I was under the impression that was a 'nono' and it is better just to
refetch the data?

Or is it the norm to grab a dataset and do updates and fills on it just as
if it was a windows app and store it into a session variable.

Thanks,

Miro
 
I was under the impression that was a 'nono' and it is better just to
refetch the data?

Storing in Session in ASP was really bad. It is only partially bad in
ASP.NET. ;-)

In general, session is not my favorite way, as you can end up screwing
yourself if you do this on multiple pages and do not spend time
planning. ViewState is a better option in many cases, but make sure you
understand the Page model, or you can end up with strange results.
ViewState can get rather large, which leads people back to Session or
Cache.

As for the 'nono' part, it is often easier to fetch and redisplay. But,
if the data is manipulated a lot, however, it makes more sense to cache
somewhere (cache, session, viewstate) rather than churning the data over
and over again. the caching option depends mostly on your needs, but can
go to the skill of the programming team, as well.

Without knowing the app in question, I cannot say whether session was a
bad idea.

Peace and Grace,


--
Gregory A. Beamer (MVP)

Twitter: @gbworld
Blog: http://gregorybeamer.spaces.live.com

*******************************************
| Think outside the box! |
*******************************************
 
Thanks for the info.

Cheers'

Miro

Gregory A. Beamer said:
Storing in Session in ASP was really bad. It is only partially bad in
ASP.NET. ;-)

In general, session is not my favorite way, as you can end up screwing
yourself if you do this on multiple pages and do not spend time
planning. ViewState is a better option in many cases, but make sure you
understand the Page model, or you can end up with strange results.
ViewState can get rather large, which leads people back to Session or
Cache.

As for the 'nono' part, it is often easier to fetch and redisplay. But,
if the data is manipulated a lot, however, it makes more sense to cache
somewhere (cache, session, viewstate) rather than churning the data over
and over again. the caching option depends mostly on your needs, but can
go to the skill of the programming team, as well.

Without knowing the app in question, I cannot say whether session was a
bad idea.

Peace and Grace,


--
Gregory A. Beamer (MVP)

Twitter: @gbworld
Blog: http://gregorybeamer.spaces.live.com

*******************************************
| Think outside the box! |
*******************************************
 
Thanks for the info.

Cheers'

Miro

Mark Rae said:
As Greg has (correctly) pointed out, this sort of internal page
persistence is what ViewState is for.

However, it's not *always* bad to persist data from databases in other
places.

E.g. if you had an application where you needed to know information about
the current user, maybe email address, department, home address etc, it
can make sense to fetch this data once at logon time and store it as a
Session variable, so long as it's not too large. This prevents unnecessary
database queries.

Some people (myself included) use Application memory to persist data which
(almost) never changes e.g. countries and their country codes, currency
codes, time zones etc...
 
Back
Top