a) It makes it hard to do something like structKeyExists()
b) If you later to change to non-integer IDs (something I've seen many apps do), you'll need to touch a lot of code that you won't need to touch if you use structs
c) Null entries in arrays aren't dealt with very gracefully in CF (this is, in some ways, related to "a)")
If you have very large data sets, you might even look at java solutions for the data caching -- there are plenty of methods for that kind of thing out there. If you are storing only, say, a few thousand records, CF structs should be just fine.
More generally, I think it's not at all crazy to store things based on ID in a struct underneath a CFC interface. One thing to consider is building a separate caching API that your other CFCs can use, which will encapsulate your particular implementation even better. Then, if later you decide to change how your caching works, you won't need to dig into lots of "business logic" code just to make that happen (and it will make your development cleaner in the short-term).
----------------------------------------------------------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
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]
