我计划将所有的配置设置存储在应用程序的app.config部分中（使用ConfigurationManager.AppSettings类）。当用户使用应用程序的UI更改设置（点击复选框，选择单选按钮等）时，我打算将这些更改写入AppSettings。同时，在程序运行时，我计划从一个将不断处理数据的进程中不断访问AppSettings。通过UI对设置的更改需要实时影响数据处理，这就是为什么该进程将不断访问AppSettings的原因。
关于性能，这样做是否是一个好主意？在编写.Net应用程序时，使用AppSettings被认为是“正确的”存储和访问配置设置的方式，但我担心这种方法并非旨在承受持续的负载（至少在不断读取设置方面）。
如果有人有相关经验，我将非常感谢您的建议。
更新：我应该澄清一些观点。
这不是Web应用程序，因此仅为存储配置设置连接数据库可能有些过度。这是一个Windows窗体应用程序。
根据MSDN文档，ConfigurationManager不仅可用于存储应用程序级别的设置，还可用于存储用户设置。（特别重要的是，如果应用程序被安装为部分信任应用程序。）
更新2：我接受了lomaxx的答案，因为Properties确实看起来是一个很好的解决方案，而不需要添加任何额外的应用程序层（如数据库）。使用Properties时，它已经执行了其他人建议的所有缓存。这意味着所有更改和随后的读取都在内存中完成，使其非常快速。属性只有在您明确告诉它时才会将更改写入磁盘。这意味着我可以在运行时即时更改配置设置，然后只在程序退出时进行最终保存到磁盘。
关于性能，这样做是否是一个好主意？在编写.Net应用程序时，使用AppSettings被认为是“正确的”存储和访问配置设置的方式，但我担心这种方法并非旨在承受持续的负载（至少在不断读取设置方面）。
如果有人有相关经验，我将非常感谢您的建议。
更新：我应该澄清一些观点。
这不是Web应用程序，因此仅为存储配置设置连接数据库可能有些过度。这是一个Windows窗体应用程序。
根据MSDN文档，ConfigurationManager不仅可用于存储应用程序级别的设置，还可用于存储用户设置。（特别重要的是，如果应用程序被安装为部分信任应用程序。）
更新2：我接受了lomaxx的答案，因为Properties确实看起来是一个很好的解决方案，而不需要添加任何额外的应用程序层（如数据库）。使用Properties时，它已经执行了其他人建议的所有缓存。这意味着所有更改和随后的读取都在内存中完成，使其非常快速。属性只有在您明确告诉它时才会将更改写入磁盘。这意味着我可以在运行时即时更改配置设置，然后只在程序退出时进行最终保存到磁盘。
仅仅为了验证它是否能够处理我需要的负载，我在我的笔记本上做了一些测试，使用Properties每秒能够进行750,000次读取和7,500次写入操作。这远远超出了我的应用程序将永远需要的范围，所以我非常放心地使用Properties而不影响性能。