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" <dave_!!no_spam!!wurtz@asdsoftware.com> wrote in message
news:401e9c9c@news.splitrock.net...[color=blue]
> Can you expand on this:
>[color=green]
> > If you want to have the greatest flexibility, make a factory method that
> > returns the user object from userID (or overload, from sessionID). You[/color][/color]
can[color=blue][color=green]
> > then feed the Session User Object or the database user object without a
> > major re-architecture.[/color]
>
> What do you mean by 'factory method'?
>
> Thank you!
> Dave
>
> "Cowboy (Gregory A. Beamer)" <NoSpamMgbworld@comcast.netNoSpamM> wrote in
> message news:OSy0S0a6DHA.2628@TK2MSFTNGP10.phx.gbl...[color=green]
> > Because of the nature of the web (long periods of inactivity) and the[/color][/color]
fact[color=blue][color=green]
> > 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[/color]
> way[color=green]
> > 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[/color][/color]
can[color=blue][color=green]
> > 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" <dave_!!no_spam!!wurtz@asdsoftware.com> wrote in message
> > news:401e775d$1@news.splitrock.net...[color=darkred]
> > > 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[/color]
> > better[color=darkred]
> > > way to keep object information?
> > >
> > > For example, if a user logs onto the website, a user object is created[/color]
> > that[color=darkred]
> > > stores their full name, email address, street address, phone, etc.[/color][/color][/color]
This[color=blue][color=green][color=darkred]
> > > object also has methods to do 'other' things such as validations,[/color]
> > counters,[color=darkred]
> > > etc. When the user logs in, the object is instantiated. Is it ok to[/color][/color]
> keep[color=green][color=darkred]
> > > this object for the life of the session? If some items are always[/color][/color]
> needed[color=green][color=darkred]
> > > (for example maybe the full name is on the header of every page), it[/color][/color][/color]
is[color=blue][color=green]
> > very[color=darkred]
> > > 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[/color][/color]
> stored[color=green][color=darkred]
> > > in the session variable, and the object is rebuilt all of the time.[/color][/color]
> Which[color=green][color=darkred]
> > > 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?[/color][/color]
> On[color=green][color=darkred]
> > > the other hand, recreating the user object each time would potentially[/color]
> > have[color=darkred]
> > > to requery the database to retrieve information - is this going to[/color][/color][/color]
kill[color=blue]
> my[color=green][color=darkred]
> > > performance?
> > >
> > > Any help on this would be very much appreciated!
> > >
> > > Thanks.
> > >
> > > Dave Wurtz
> > > Advanced Software Designs
> > >
> > >[/color]
> >
> >[/color]
>
>[/color]
