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