Recently, I discovered that the "Web.Config" file contains an <appSettings>
section which seemed good for storing one's Application Settings. Heck, it even has a programmatic way to access the file thru a standard System library. So being all clever, I wrote an Interface to access it and then a Concrete implementation of the interface, shown here:
public interface IAppSettings
{
IEnumerable<string> GetValues(string componentName, string settingName);
IEnumerable<KeyValuePair<string, string>> GetValuePairs(string componentName, string settingName);
void SetValues(string componentName, string settingName, IEnumerable<string> valueList, bool append);
void SetValuePairs(string componentName, string settingName, IEnumerable<KeyValuePair<string, string>> pairList, bool append);
}
Then I came to discover that saving settings back to "web.config" while the application is running causes the entire application to re-start. This seems completely unreasonable to me because if I'm writing back to web.config a lot and the application is restarting each time, then things like HttpRuntime.Cache get completely emptied effectively making my Cache useless because it's constantly emptying and repopulating.
So I'm wondering: Where should I store my Application Settings?
Is there a good solution out there for this so that I don't have to roll my own?
EDIT:
Okay, thanks to everyone who suggested using a DB and a potential table schema. I think I'm going to go with the following schema:
settings:
index NUMBER NOT NULL AUTO_INCREMENT <== Primary Key
component NVARCHAR(255) NOT NULL
setting NVARCHAR(255) NOT NULL
key NVARCHAR(255)
value NVARCHAR(255) NOT NULL
Though I don't think I'll make the "setting" the P-Key, but use an Auto-Incr Index instead. This way if I have an application that needs to mail something to multiple managers, I can store many:
index component setting value
1 RequestModule ManagerEmail manager1@someplace
2 RequestModule ManagerEmail manager2@someplace
And then I can use:
IEnumerable<string> GetValues(string componentName, string settingName);
And it will return a list of email addresses, rather than just a single value.
Does this make sense?
These config files are typically placed under separate root directory than the rest of application code. For example, in case of Java they are typically under src/main/resources .
Settings are stored by default in the local user. config file.
Application settings enables developers to save state in their application using very little custom code, and is a replacement for dynamic properties in previous versions of the . NET Framework.
web.config is generally used for read-only settings, ie. the settings set during deployment of the application by the system administrator.
If you want to read and write the settings, the most obvious way is to use the database. By the way, this has an advantage: an application can be hosted on several servers and will still read and write the settings correctly,
You can also implement your custom storage for the settings, but it will be probably more difficult to implement and not much faster.
To answer your second question, the structure of your database depends on the type of settings you want to store.
If you need to store heterogeneous unique entries like this:
then you have to use varchar
s or other more or less friendly types as keys to identify the entries (rather than to refer to them by their index).
On the other hand, if your purpose is to store the mail addresses of several managers, you should create a Manager
table containing their mail addresses, names, datetime of their last connection, etc.
You really shouldn't mix both. In theory, you can refer to the entry in settings by component/setting pair. In practice, it makes things harder and creates a bunch of problems:
Storing settings in web.config is useful because it makes it easy to have different settings in different environments. However, as you say, this is no use if you are likely to want to change the settings in a live environment.
A simple database table is the most useful way to do this if you need to change the values.
eg.
create table Settings
(Name varchar(50) primary key,
Value varchar(50))
If you're using SQL Server, you can set to the Value
column to be sql_variant
which will allow you to store a variety of datatypes.
If you love us? You can donate to us via Paypal or buy me a coffee so we can maintain and grow! Thank you!
Donate Us With