There are, it seems to me, two issues.
The first is the interface a developer will use to get at this information. The second is how you choose to implement the interface.
More specifically, you might start with designing the interface that lets a developer say something like:
application.myCFCService.getStuff(session.company_id);
You might then choose to implement the caching mechanism down inside myCFCService (or perhaps some other layer below that) that stores things in a struct based on company ID.
I think you are asking more about the implementation aspects, rather than the interface decisions, but I think it's worth pointing out that you can do the first without necessarily doing the second. If you are looking for opinions 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. The trick is to be sure you have a good way to update your cache if/when the data changes -- this usually involves making the caching mechanism used during data retrieval also part of the path for updating data -- that way you can always update the cache behind the scenes, without making the end developer (even if that's you) worry about it.
Is this the kind of feedback you were looking for?
Barry L Beattie wrote:
----------------------------------------------------------firstly let me preface this post with two cavats: 1) I'm just looking for opinions, thoughts, etc to sway the decision one way or another. "Should we or shouldn't we" stuff 2) IMHO, the power (ands flexability) of CFC's comes from not just calling methods but in it's ability to store context data/values as well - "objects"
For our enterprise app at the moment (a web version of a 15 yo legacy app), all data is returned based on what company_id a user has logged in at. this means that every db table, every method call - everything - needs this company_id to work (ie: each db table stores multiple company data where the companies are subsets of a particular organisation).
(pls note: this is a legacy app - while I would not do things this way if I had a clean slate, it *does work*...)
this means that for app-wide values (not specific entity data) either:
- it may be pointless to store db data as object properties (depends on the user's context - session.company_id - from the login process) so the server-stored CFC's turn into no more than collections of UDF OR...
- store cfc properties as arrays, based on company_id. sure this is more work, but at least we can persist "objects" in server scope and cut down on the db hits
I know this is a wierd set-up but if anyone has any thoughts, opinions, advice, etc I'm all ears.
thanx barry.b
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]
