thanx Nathan >> The first is the interface a developer will use to get at this information. The >> second is how you choose to implement the interface.
>> I think you are asking more about the implementation aspects, rather than the >> interface decisions that pretty much sums it up. "Should these CFC's store instance data (considering the circumstances) and if so, what's the best way". >> More specifically, you might start with designing the interface that lets a >> developer say something like: application.myCFCService.getStuff(session.company_id); this we are used to. there is already a large code base in ancillery apps that do this (most don't use CFC's or the the data is not being persisted within the CFC) where the "session.company_id" is needed on every method call >>... on building CFC-encapsulated caching based on some known set of IDs, I can tell >>you I've done stuff like that with great success in the recent past. so this is not too far off the deep end, eh? >> The trick is to be sure you have a good way to update your cache if/when the data >> changes yes. the method call looks for existing data and, if not found, retrieves, returns and caches it. >> Is this the kind of feedback you were looking for? yes, especially the "that stores things in a struct based on company ID." isn't that far off the wall. one final question: structOstructs? arrStructs? strArrays? (the persist layer already converts all queries/retrieved data to arrStructs at the moment) cheers barry.b -- ___________________________________________________________ Sign-up for Ads Free at Mail.com http://promo.mail.com/adsfreejump.htm ---------------------------------------------------------- You are subscribed to cfcdev. To unsubscribe, send an email to [EMAIL PROTECTED] with the words 'unsubscribe cfcdev' in the message of the email. CFCDev is run by CFCZone (www.cfczone.org) and supported by Mindtool, Corporation (www.mindtool.com). An archive of the CFCDev list is available at www.mail-archive.com/[EMAIL PROTECTED]
