Jeff Chastain wrote, On 6/7/2007 4:06 PM:
Is there any reasoning / logic behind having your configuration
information stored in a bean vs. some other method? I have seen some
applications design using a collection of configuration beans and
other applications designed using an xml file that is just read and
parsed into a ‘config’ structure. If your configuration information is
not really changing (maybe this is a bad assumption), is there any
reason for having the extra overhead of the beans and their
instantiation instead of just a static structure of key = value pairs?
There may be encapsulation issues, for example if you don't want your
components that use the configuration to be too tightly coupled to the
/implementation/ of that configuration. Now, you can avoid this yourself
(though experience has shown it is hard to do), but having it as a bean
means you can change any any of the implementation details and be fairly
sure its not going to break any code that relies on it (since the
implementation details, presumably, were hidden).
Sam
Thanks
-- Jeff
*From:* [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] *On Behalf Of
*Peter Bell
*Sent:* Thursday, June 07, 2007 3:44 PM
*To:* cfcdev@cfczone.org
*Subject:* Re: [CFCDEV] Application.cfc: where to set DSN
+1. Only thing I put into application.cfc (in terms of a config
property) is application.name which I need to include the framework
that calls the application specific config bean that contains all of
the other app specific config info. Encapsulating it in a config bean
gives you a bunch more flexibility to change how it is created or
stored without breaking the API you expose to the rest of your app.
Best Wishes,
Peter
You are subscribed to cfcdev. To unsubscribe, please follow the
instructions at http://www.cfczone.org/listserv.cfm
CFCDev is supported by:
Katapult Media, Inc.
We are cool code geeks looking for fun projects to rock!
www.katapultmedia.com
An archive of the CFCDev list is available at
www.mail-archive.com/cfcdev@cfczone.org
You are subscribed to cfcdev. To unsubscribe, please follow the instructions at
http://www.cfczone.org/listserv.cfm
CFCDev is supported by:
Katapult Media, Inc.
We are cool code geeks looking for fun projects to rock!
www.katapultmedia.com
An archive of the CFCDev list is available at
www.mail-archive.com/cfcdev@cfczone.org
