Hi Richard, Because it's easier! There is no right or wrong answer to this in the general case. What is more valuable - a simpler application or one that is slightly more efficient? Creating a single object per request isn't a big overhead for most applications (although checking a remote db for the data can get expensive pretty quick).
To me, the most important thing is to encapsulate the object creation using a factory so it would be trivial to change the design choice as required. A lot of this will depend upon how much of the session scoped data will be changed frequently, how likely the users are to run multiple concurrent sessions and how catastrophic a little bit of data loss here and there would be. As long as you have a user factory making your caching decisions, none of your code will break if you move between request instantiation, session instantiation or even application instantiation (using an object pool - it COULD happen). That said, without the above data, I'd probably do the same as Dave, but this is something I'd add when I had a working application, not when I was putting together the first cut! Best Wishes, Peter -----Original Message----- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Dave Ross Sent: Sunday, June 25, 2006 11:22 AM To: CFCDev@cfczone.org Subject: Re: [CFCDev] Instances and persisted data That's not my advice. If it's session-based data, put it in the session. If it needs updating, update it. Why create additional load on your system by recreating everything upon each request? -Dave On 6/25/06, Richard <[EMAIL PROTECTED]> wrote: > Thaks to everyone for their quick and detailed responses. A lot to > take on board. However would I be oversimplifying things if say that > the advice is not to instantiate objects in the session scope just to > make data available for the session? On each page request, instantiate > a new object and populate it from the DB or wherever? > > > > > ---------------------------------------------------------- > You are subscribed to cfcdev. To unsubscribe, send an email to > cfcdev@cfczone.org with the words 'unsubscribe cfcdev' as the subject > of the email. > > CFCDev is run by CFCZone (www.cfczone.org) and supported by CFXHosting > (www.cfxhosting.com). > > An archive of the CFCDev list is available at > www.mail-archive.com/cfcdev@cfczone.org > > > ---------------------------------------------------------- You are subscribed to cfcdev. To unsubscribe, send an email to cfcdev@cfczone.org with the words 'unsubscribe cfcdev' as the subject of the email. CFCDev is run by CFCZone (www.cfczone.org) and supported by CFXHosting (www.cfxhosting.com). An archive of the CFCDev list is available at www.mail-archive.com/cfcdev@cfczone.org ---------------------------------------------------------- You are subscribed to cfcdev. To unsubscribe, send an email to cfcdev@cfczone.org with the words 'unsubscribe cfcdev' as the subject of the email. CFCDev is run by CFCZone (www.cfczone.org) and supported by CFXHosting (www.cfxhosting.com). An archive of the CFCDev list is available at www.mail-archive.com/cfcdev@cfczone.org
