Business Objects and Session Variables

[Dave Wurtz]

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

 

[Cowboy \(Gregory A. Beamer\)]

Because of the nature of the web (long periods of inactivity) and the fact
that a user object is generally low perf hit to fill (via database
retrieval), I do not see as great a benefit to dropping objects into
session, but I am not adverse to it either.

The biggest question, for your app, is which is going to cause more
problems:
1. A bunch of unused objects in memory for extended periods of time (20
minutes after last hit by default)
2. Hitting the database to get user info when a user requests a page

In some apps, the memory usage will kill scalability. For others, the
minimal lag to the RDBMS is the killer. In most, it does not matter one way
or the other.

If you want to have the greatest flexibility, make a factory method that
returns the user object from userID (or overload, from sessionID). You can
then feed the Session User Object or the database user object without a
major re-architecture.

--
Gregory A. Beamer
MVP; MCP: +I, SE, SD, DBA

**********************************************************************
Think Outside the Box!
**********************************************************************

 

[Guest]

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-Thac

----- 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 bette
way to keep object information

For example, if a user logs onto the website, a user object is created tha
stores their full name, email address, street address, phone, etc. Thi
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 kee
this object for the life of the session? If some items are always neede
(for example maybe the full name is on the header of every page), it is ver
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 store
in the session variable, and the object is rebuilt all of the time. Whic
way is better

Storing the user object for the life of the session is definitely mor
convenient for the programmer, but is it going to kill my performance? O
the other hand, recreating the user object each time would potentially hav
to requery the database to retrieve information - is this going to kill m
performance

Any help on this would be very much appreciated

Thanks

Dave Wurt
Advanced Software Design

 

[Guest]

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

 

[Dave Wurtz]

Can you expand on this:

If you want to have the greatest flexibility, make a factory method that
returns the user object from userID (or overload, from sessionID). You can
then feed the Session User Object or the database user object without a
major re-architecture.

What do you mean by 'factory method'?

Thank you!
Dave

 

[Patrice Scribe]

Addtionaly make sure it doesn't matter to your app. If you are uses a
classes that protects your app from implementation details you'll be able to
balance this behavior as needed....

Patrice

 

[Cowboy \(Gregory A. Beamer\)]

General:
--------
Best bet is to look at www.dofactory.com, as there are a lot of
implementations of patterns here. Microsoft also has some great (free) books
on architecture using patterns at http://msdn.microsoft.com/architecture -
look at Patterns and Practices.

A factory method (using a factory pattern) is one that returns an object to
you based on certain criteria. When you implement a factory pattern, you
have the option of later adding cache capabilities. This is more flexible
than simply creating a user object. In addition, you can abstract the
factory method to allow you to return slightly different objects derived
from the same base class (for example, a visitor object, an employee object
and an administrator object -- each with different levels of access, but
each derived from a base user object).

Specific:
--------
The main point I was making with the factory method, is you can then
determine whether you need to store the object in session, or reconstitute
it from the database on each hit.

public User GetUserObject(long userID)
{
}

public User GetUserObject(string sessionID)
{
}

With these two methods, you can either pull from session or rebuild from the
database. In your code, the call will still be something like:

string SessionID = Session.ID.ToString();
User user = GetUserObject(sessionID);

Initially, the internals for the GetUserObject() method are pulling from
Session, like:

public User GetUserObject(string sessionID)
{
return (User) Session["User"];
}

But, you could flip to rebuilding each time, if it works better, without
refactoring all of your calls, which would be spread throughout your ASP.NET
application.

--
Gregory A. Beamer
MVP; MCP: +I, SE, SD, DBA

**********************************************************************
Think Outside the Box!
**********************************************************************

 

[Cowboy \(Gregory A. Beamer\)]

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!
**********************************************************************

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.

 

[Ravichandran J.V.]

Have you tried inserting the object reference into a cache object and
retreiving it in the subsequent pages?

Page1.aspx
Private conn as SqlConnection

conn=new SqlConnection(connStr)

Cache.Insert("myOb",conn);

Page2.aspx

Private conn as SqlConnection
private o as Object=Cache.Get("myOb")
conn=CType("o",SqlConnection)

The cache object can be retained in the memory for a max of 5 minutes
only.

with regards,


J.V.Ravichandran
- http://www.geocities.com/
jvravichandran
- http://www.411asp.net/func/search?
qry=Ravichandran+J.V.&cob=aspnetpro
- http://www.southasianoutlook.com
- http://www.MSDNAA.Net
- http://www.csharphelp.com
- http://www.poetry.com/Publications/
display.asp?ID=P3966388&BN=999&PN=2
- Or, just search on "J.V.Ravichandran"
at http://www.Google.com