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 8 3155
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!
************************************************** ********************
"Dave Wurtz" <da*******************@asdsoftware.com> wrote in message
news:40********@news.splitrock.net... 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
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
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
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
"Cowboy (Gregory A. Beamer)" <No************@comcast.netNoSpamM> wrote in
message news:OS**************@TK2MSFTNGP10.phx.gbl... 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! ************************************************** ******************** "Dave Wurtz" <da*******************@asdsoftware.com> wrote in message news:40********@news.splitrock.net... 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
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
--
"Dave Wurtz" <da*******************@asdsoftware.com> a écrit dans le message
de news:40********@news.splitrock.net... 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
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!
************************************************** ********************
"Dave Wurtz" <da*******************@asdsoftware.com> wrote in message
news:40******@news.splitrock.net... 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
"Cowboy (Gregory A. Beamer)" <No************@comcast.netNoSpamM> wrote in message news:OS**************@TK2MSFTNGP10.phx.gbl... 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! ************************************************** ******************** "Dave Wurtz" <da*******************@asdsoftware.com> wrote in message news:40********@news.splitrock.net... 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
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" <an*******@discussions.microsoft.com> wrote in message
news:35**********************************@microsof t.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 This thread has been closed and replies have been disabled. Please start a new discussion. Similar topics
by: headware |
last post by:
I am new to 3-tiered design and am in the process of designing an
application that will work with ASP.NET as well as Windows Forms (and
possibly with a PDA of some sort down the road). My question...
|
by: Keith-Earl |
last post by:
Okay, looking for a Best Practice. We are building a classic three tier app
in VB.NET. When we load up a WebForm we have access to very useful objects
such as the Session object. We frequently...
|
by: tshad |
last post by:
I am trying to set up a reusable library (business component) that I can use
in a bunch of my pages.
I built the file and it almost compiles, but I am not sure what I am
missing.
The vbc...
|
by: Andy Kasotia |
last post by:
I have read couple of articles warning against the use of storing VB COM
objects (Apartment Threading) in Session Variables due to the fact that
these variables could go bad.
My question is...
|
by: Not Me |
last post by:
Hi,
I have a set of pages that use forms authentication for access. There
are times when one of the session objects I'm using appears to
disappear. The session is not timing out, however. (if...
|
by: Mike |
last post by:
Hello,
I am working on a ASP.NET 1.1 project and would like to set up the web
application to only have one unique Business Logic object that is created
when the client connects. I would like to...
|
by: Guy Thornton |
last post by:
I have an application in asp.net using vb.
The asp.net portion of this application is mainly the user interface. The
UI has references made to our business logic layer. And the business logic...
|
by: Thom Anderson |
last post by:
Hi, I have some business objects that are pretty simple. They get
instantiated and have a few properties, methods, and events. The business
objects talk to the database directly or access web...
|
by: Showjumper |
last post by:
Hi
I have custom bustom objects whose properties i populate using a datareader.
Is it possible to cache the business object afteri have populated it? If so,
how? Everything i have tried does not...
|
by: Charles Arthur |
last post by:
How do i turn on java script on a villaon, callus and itel keypad mobile phone
|
by: emmanuelkatto |
last post by:
Hi All, I am Emmanuel katto from Uganda. I want to ask what challenges you've faced while migrating a website to cloud.
Please let me know.
Thanks!
Emmanuel
|
by: nemocccc |
last post by:
hello, everyone, I want to develop a software for my android phone for daily needs, any suggestions?
|
by: Hystou |
last post by:
There are some requirements for setting up RAID:
1. The motherboard and BIOS support RAID configuration.
2. The motherboard has 2 or more available SATA protocol SSD/HDD slots (including MSATA, M.2...
|
by: Hystou |
last post by:
Most computers default to English, but sometimes we require a different language, especially when relocating. Forgot to request a specific language before your computer shipped? No problem! You can...
|
by: jinu1996 |
last post by:
In today's digital age, having a compelling online presence is paramount for businesses aiming to thrive in a competitive landscape. At the heart of this digital strategy lies an intricately woven...
|
by: tracyyun |
last post by:
Dear forum friends,
With the development of smart home technology, a variety of wireless communication protocols have appeared on the market, such as Zigbee, Z-Wave, Wi-Fi, Bluetooth, etc. Each...
|
by: agi2029 |
last post by:
Let's talk about the concept of autonomous AI software engineers and no-code agents. These AIs are designed to manage the entire lifecycle of a software development project—planning, coding, testing,...
|
by: isladogs |
last post by:
The next Access Europe User Group meeting will be on Wednesday 1 May 2024 starting at 18:00 UK time (6PM UTC+1) and finishing by 19:30 (7.30PM).
In this session, we are pleased to welcome a new...
| |