Re: Business Objects and Session Variables
From: Cowboy \(Gregory A. Beamer\) (NoSpamMgbworld_at_comcast.netNoSpamM)
Date: 02/03/04
- Next message: Cowboy \(Gregory A. Beamer\): "Re: Killing off my sessions"
- Previous message: Cowboy \(Gregory A. Beamer\): "Re: Business Objects and Session Variables"
- In reply to: Tim Stall: "RE: Business Objects and Session Variables"
- Next in thread: Patrice Scribe: "Re: Business Objects and Session Variables"
- Messages sorted by: [ date ] [ thread ]
Date: Tue, 3 Feb 2004 08:07:23 -0600
The DB hit is not normally too bad on most modern networks. Since there is a
certain amount of pooling of connections, you are not taking the most major
part of the hit each time. Is it a much greater hit than caching? Certainly.
But, it is not critical in many applications. The question is where you wish
to cache. You can use Session to easily cache without building anything. Or,
you can set up your own caching mechanism.
-- Gregory A. Beamer MVP; MCP: +I, SE, SD, DBA ********************************************************************** Think Outside the Box! ********************************************************************** "Tim Stall" <anonymous@discussions.microsoft.com> wrote in message news:35E966A2-9B9B-4F55-AC13-8881871B7486@microsoft.com... > You could also store it in the Cache (if it is a commonly used object) or ViewState (for the scope of a single page). > > Storing everything in session may give you huge performance hits, and make testing very difficult (it's generally harder to test Session objects because they could "interfere" with the session on other pages, as opposed to viewstate). Also, as the scope of Session could be for multiple pages, and you're looking for a scope that covers just the postback of a single page (I assume), session would give you more than you needed. > > You're right that generally, storing the PK and rehitting the DB will be a *major* performance hit. > > Tim > > > ----- Tu-Thach wrote: ----- > > Dave, > I usually store information that are needed frequently in session that saves me from querying the database. Just as you mentioned, there will be tradeoffs for either approach that you go with. The point to use use it appropriately so that you minimize the potential problems. > > Tu-Thach > > ----- Dave Wurtz wrote: ----- > > All, > > I'm new to ASP development and I have a basic design question: > > Is it ok to store business objects to session variables or is there a better > way to keep object information? > > For example, if a user logs onto the website, a user object is created that > stores their full name, email address, street address, phone, etc. This > object also has methods to do 'other' things such as validations, counters, > etc. When the user logs in, the object is instantiated. Is it ok to keep > this object for the life of the session? If some items are always needed > (for example maybe the full name is on the header of every page), it is very > convenient just to call a property off of the user object. > > I've also seen some examples where the primary key of the object is stored > in the session variable, and the object is rebuilt all of the time. Which > way is better? > > Storing the user object for the life of the session is definitely more > convenient for the programmer, but is it going to kill my performance? On > the other hand, recreating the user object each time would potentially have > to requery the database to retrieve information - is this going to kill my > performance? > > Any help on this would be very much appreciated! > > Thanks. > > Dave Wurtz > Advanced Software Designs > > >
- Next message: Cowboy \(Gregory A. Beamer\): "Re: Killing off my sessions"
- Previous message: Cowboy \(Gregory A. Beamer\): "Re: Business Objects and Session Variables"
- In reply to: Tim Stall: "RE: Business Objects and Session Variables"
- Next in thread: Patrice Scribe: "Re: Business Objects and Session Variables"
- Messages sorted by: [ date ] [ thread ]
Relevant Pages
|