Where to Store Application Settings

In .NET programming, it's standard practice to store application settings in XML documents (usually with a .config extension). The difficulty arises when you need or want to have your application behave differently in different situations. You must either support this in the configuration file or look to a data-driven settings architecture in which you use data to configure your application. If you choose the latter solution, a database is the natural place to store the data that drives your application's settings.

Before you adopt the data-driven settings model, you should first understand some of the reasons to use configuration files for your application. If your application does not require a database for any other function, you may not want to include database functionality for the application settings only. Likewise, if your application requires settings during startup, a database is typically not available at that point in the process, so a configuration file is a more natural solution. (In the past, application settings in these situations were often stored in the Windows Registry, but currently they are more often stored with the application in configuration files.). One of the chief advantages of storing your application's configuration settings in a file is that the file can easily be manipulated by the user. An XML file can be edited in Notepad, so any user can modify the settings. If you need to prevent users from viewing or manipulating sensitive settings, configuration files can be encrypted.

Although not readily available during application startup, application settings stored in a database can be advantageous. In a database, you can control access to the settings using database security, including encryption in SQL Server 2005. This helps keep users who might not understand the impact of their changes from easily modifying settings. If you are using some form of role-based security (see Chapter 2, "Basic Database Security Principles"), you can manage who has the ability to change individual application settings. Application settings stored in the database are also helpful in distributed applications. Thus, you will be able to store settings, such as timezone or office policies, in one placethe database. These settings can be managed by the appropriate personnel and can be set up so that the application has different versions of settings for different users or groups of users. Table 1-1 shows the advantages offered by both of the two options.

Table 1-1. Application Settings Storage Comparison

Feature	Database Storage	Configuration File Storage
User can easily modify settings
Application does not require a database engine
Settings are readily available during application startup
Application can implement role-based security
Application can implement centralized control of settings
Application can easily restrict access to settings
Application can provide for granular control of settings

Tip

If you want to take advantage of settings stored in a database, but you don't want to burden your client with a full-service database, consider implementing database-stored application settings using Microsoft SQL Server 2005 Express Edition, which is free, or using Microsoft SQL Server 2005 Workgroup Edition, which has a compelling price point for smaller implementations.

As you can see from the comparison in Table 1-1, you will need to choose the option that best suits your application. There is no absolute right answer concerning whether the application settings should be stored in a database or a configuration file. Carefully evaluate your needs and environment and use the the information presented here to make the appropriate decision for your application.