我打算在我的应用程序的app.config部分中存储我的所有配置设置（使用ConfigurationManager.AppSettings类）。当用户使用应用程序的UI更改设置（单击复选框，选择单选按钮等）时，我计划将这些更改写入AppSettings。同时，在程序运行的同时，我计划从一个不断处理数据的过程中不断访问AppSettings。通过UI对设置的更改需要实时影响数据处理，这就是进程将不断访问AppSettings的原因。
这是一个关于性能的好主意吗？在编写.Net应用程序时，使用AppSettings应该是存储和访问配置设置的“正确方法”，但我担心这种方法不适用于恒定负载（至少在设置不断读取方面）。
如果有人有这方面的经验，我将非常感谢输入。
更新：我应该澄清几点。
这不是一个Web应用程序，因此将数据库连接到应用程序可能仅仅是为了存储配置设置而过度杀伤。这是一个Windows窗体应用程序。
根据MSDN文档，ConfigurationManager不仅用于存储应用程序级别设置，还用于存储用户设置。 （例如，如果将应用程序安装为部分信任应用程序，则尤为重要。）
更新2：我接受了lomaxx的回答，因为Properties确实看起来确实是一个很好的解决方案，而无需向我的应用程序添加任何其他层（例如数据库）。使用“属性”时，它已经完成了其他人建议的所有缓存。这意味着任何更改和后续读取都在内存中完成，使其非常快。属性仅在您明确告知磁盘时将更改写入磁盘。这意味着我可以在运行时动态更改配置设置，然后在程序退出时只进行最终保存到磁盘。
只是为了验证它实际上能够处理我需要的负载，我在笔记本电脑上做了一些测试，并且能够使用Properties执行750,000次读取和每秒7,500次写入。这远远超出我的应用程序甚至接近需要我在使用Properties而不影响性能时感觉非常安全。
因为你正在使用winforms应用程序，如果它在.net 2.0中，实际上有一个用于此目的的用户设置系统（称为属性）。 This article on MSDN对此有一个很好的介绍
如果你仍然担心性能，那么看一下类似于SQLite的SQL Compact Edition，但是我发现的微软产品与winforms非常相配，甚至还有make it work with Linq的能力
查看SQLite，它似乎是这个特定场景的一个很好的选择。
迪伦，
不要将应用程序配置文件用于此目的，使用SQL DB（SQLite，MySQL，MSSQL等），因为在读取和写入配置文件期间，您不必担心并发问题。
您还可以更灵活地存储要存储的数据类型。 appSettings部分只是一个键/值列表，随着时间的推移和应用程序的成熟，您可能会长大。您可以使用自定义配置部分，但是当涉及到设计时，您将进入一个新的问题区域。
appSettings并不真正意味着您要做的事情。
当您的.NET应用程序启动时，它会读入app.config文件，并将其内容缓存在内存中。因此，在您写入app.config文件之后，您必须以某种方式强制运行时重新解析app.config文件，以便它可以再次缓存设置。这是不必要的
最好的方法是使用数据库来存储配置设置。
除了使用数据库，您可以轻松设置外部XML配置文件。应用程序启动时，可以将其内容缓存在NameValueCollection对象或HashTable对象中。当您更改/添加设置时，您将对该缓存副本执行此操作。当应用程序关闭时，或者以适当的时间间隔，您可以将缓存内容写回文件。
如果我错了，有人会纠正我，但我不认为AppSettings通常意味着用于这些类型的配置设置。通常，您只会放入保持相当静态的设置（数据库连接字符串，文件路径等）。如果要存储可自定义的用户设置，最好创建单独的首选项文件，或者理想地将这些设置存储在数据库中。
我不会使用配置文件来存储用户数据。使用数据库。
我可以问你为什么不将用户的设置保存在数据库中？
通常，我会保存在appSettings部分中很少更改的应用程序设置（发送默认电子邮件地址错误日志，自动注销后的分钟数等）。这个范围真正适用于应用程序而不是用户，通常用于部署设置。
我要做的一件事是在读取时缓存appsettings，然后在写入时从缓存中刷新设置，这应该最小化服务器处理appSettings时必须处理的实际负载量。
此外，如果可能，请查看将appSettings分解为configSections，以便您可以读取写入和缓存相关的设置。
说了这么多，我会认真考虑将这些值存储在数据库中，因为您似乎实际上存储的是用户首选项，而不是应用程序设置。