If the structure of your configuration information doesn¹t change, no need for the bean. In my experience, things change. Having a bean allows you to encapsulate certain classes of change (not all, but some) without breaking your API/contract with the rest of the app.
Also I find the bean allows me to add optional automagic. So if for a given project you don¹t set a DSN it assumes it to be the application name (for instance), if you don¹t set whether the system uses forward or back slashes, you can write a script in the bean to determine that at runtime. You don¹t care when you call configuration information whether it was calculated or set only that it is available. I find the encapsulation of a bean to be a really nice way to allow me to change how I configure an app without necessarily having to change how the app accesses that config info. Best Wishes, Peter On 6/7/07 5:06 PM, "Jeff Chastain" <[EMAIL PROTECTED]> wrote: > 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? > > 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
