Resources/App.config or Database where is the best place to application strings

Question

All,

I was currently looking at on old application that I am maintianing and it uses a mixture of retrieving Application config settings from both the App.config and application config table in the DB.

In the new software I am working (a port of the old application) I have a list of email addresses that are static and rarely change, what would be the best mechanism for retrieving these. Currently I am using resource strings so that using them is a simple My.Resources., but what are the benefits/drawbacks of storing the information either in the App.Config or a database table.

At what point does it not make sense to use resources?

Answer 1

I think the rarely changing settings can safely go to app.config. This was its fairly transparent where they come from for new developers on the team, and still it is possible to change the setting without recompile.

For thing that change often and regularly, I would use either database, settings file in user's profile or other shared location, etc. Something that would make managing the changes in configuration easier.

On the other hand, I don't think that resource file is though to be used for storing configuration, it is rather to centralize (and in some cases keep translations, etc) of all hardcoded stuff in your application. I would be very surprised if I inherited your code.

Answer 2

It all depends? some of my rules of thumb are

for going into a config/resource file

1. it's the same for every user, like the path to an image directory
2. the data is only needed at the UI level and will not change very often, like a list of US States
3. it may vary from server to server, like a resource URL for production vs testing

for going into a DB

1. It changes per user or is user specific data
2. it may need to be maintained by someone out side your development group
3. It's going to be used outside of the UI layer
4. it's going to be updated regularly

what ever you do

DON'T HARD CODE STRING INTO YOUR CODE, I don't care how positive you are that the bug report notify Email address will not change, DO NOT HARD CODE IT!!!! or 3 years down the road what would have been a 2 sec config change will result in 2 weeks of work to get an out dated legacy piece of crap application to compile!! or another fun one was an xml-schema hard coded into an application with

stringname += "Schema data";
stringname += "Schema data";
stringname += "Schema data";

Oddly enough same guy, go figure.

Answer 3

I'm for putting the bare minimum in configuration files. Just enough to get connected to your database or whatever else you are using as a data source. This is less information that is exposed in a flat file somewhere. For storing emails I would put that in the DB.