Hi Richard, Just a couple of tangential points as you state you're new to cfc's. Apologies if they're obvious.
Firstly, it looks like you could be performing premature optimization (insert sophomoric humor here). Obviously you need a way to uniquely track views to a user within a session - perhaps for tracking, personalization or security, so you need to store some kind of ID or UUID. It will probably also be a good idea to store user info to save the per request db queries, but whether that performance optimization is worth the trouble of writing a whole isDirty/optimistic locking caching schema with business rules for handling exceptions at either a field or record level is another question. I'd start by putting a simple getUser() into your user service (or separate factory if you wish) to instantiate a user object per request and to get the app up and working, I would just call from the db each time. If you then needed to cache the user in session scope you could do it by adding just a couple of lines to your UserService.getUser() along the lines of "if this user exists in session scope, return it (after doing any isdirty checking) else instantiate this user in session scope". That way the initial app is simple so you can focus on your business logic, and it will be easy to change scope to application or any other scope if you want non-session based caching in the future. Of course, if you have multiple user sessions or any other possible situations where you're worried about data loss due to concurrent editing, you're going to have to write some optimistic locking where you either have a "LastModified" datetime metadata field which is passed around with each object on load and compared, or you could have record by record comparisons by always keeping a copy of the original record in the bean and comparing the results of a getOld%FieldName%() with get%FieldName% with getcurrent%FieldName% to fix most of the conditions automatically. You also need to handle the conventions for returning this data as part of your service layer and/or activerecord API. Good luck. It isn't rocket science, but it is a good few hours of messing around. I'm putting together some sample base classes and I'll try to throw in some generic optimistic locking code that people could use as a naïve starting point when I get a chance. As a side note, the above approach still doesn't fully encapsulate session scope handling as you may have session code in each entity which you are going to persist over sessions, so you might want to get a SessionService.getObject(ObjectName: string, ObjectIdentifier: any) which the UserService.getUser() and any other service could call to truly encapsulate session state. May also be important if your application ever needs to respond to requests that don't include session state as you would only have to find the logic in one place to test for and stub out such requests. Whether this is worth it from a complexity vs. seperation of concerns perspective would depend upon how many different parts of your application might touch sessions. If n > 1, it is probably worth considering. As always, take my comments with a bucket of salt and I look forward to learning from any dissenting opinions from anyone on the list! Best Wishes, Peter -----Original Message----- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Richard Sent: Sunday, June 25, 2006 7:27 AM To: CFCDev@cfczone.org Subject: [CFCDev] Instances and persisted data Hi Everyone. I'm new to this list, and new to CFCs, so bear with me if this is obvious. I'm struggling to decide how to handle the relationship between session instance data, and persisted data stored on the back end. I have a couple of related questions 1) If I have for example a session.user instance which has instance data that the user can modify (change email etc etc) should I commit this to the database at the same time in one transaction, or should I track whether the inszance data "is dirty" and manage the commit on the basis of an explicit save by the user, and maybe use the onSessionend event 2) If a user establishes two different browser session, we have effectively two different instances. This just complicates the above. Can I trap it (application variable?), or how should I handle this? I can always just reload instance data on each request, but that seems to defeat the purpose a bit I'm not sure whether these questions are just application related or whether they are CFC/component issues. Any pointers much appreciated Cheers Richard ---------------------------------------------------------- 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
