如果我错了,有人会纠正我,但我不认为 AppSettings 通常用于这些类型的配置设置。通常,您只会放入保持相当静态的设置(数据库连接字符串、文件路径等)。如果您想存储可自定义的用户设置,最好创建一个单独的首选项文件,或者最好将这些设置存储在数据库中。
我计划将所有配置设置存储在应用程序的 app.config 部分(使用 ConfigurationManager.AppSettings
类)。当用户使用应用程序的 UI(单击复选框、选择单选按钮等)更改设置时,我计划将这些更改写入 AppSettings
。同时,在程序运行时,我计划从一个不断处理数据的进程中不断访问 AppSettings
。通过 UI 更改设置需要实时影响数据处理,这就是进程将不断访问 AppSettings
的原因。
就性能而言,这是一个好主意吗?在编写 .Net 应用程序时,使用 AppSettings
应该是存储和访问配置设置的“正确方法”,但我担心这种方法不适用于恒定负载(至少在正在不断读取设置)。
如果有人有这方面的经验,我将不胜感激。
更新:我应该澄清几点。
这不是一个 Web 应用程序,因此将数据库连接到应用程序可能只是为了存储配置设置而过大。这是一个 Windows 窗体应用程序。
根据 MSDN 文档,ConfigurationManager
不仅用于存储应用程序级设置,还用于存储用户设置。 (例如,如果应用程序安装为部分信任应用程序,则尤为重要。)
更新 2: 我接受了 lomaxx 的回答,因为 Properties
确实看起来是一个不错的解决方案,无需向我的应用程序添加任何附加层(例如数据库) .使用 Properties 时,它已经完成了其他人建议的所有缓存。这意味着任何更改和后续读取都在内存中完成,因此速度非常快。属性仅在您明确告诉它时将更改写入磁盘。这意味着我可以在运行时即时更改配置设置,然后仅在程序退出时才将最终保存到磁盘。
为了验证它实际上是否能够处理我需要的负载,我在我的笔记本电脑上做了一些测试,并且能够使用 Properties 每秒进行 750,000 次读取和 7,500 次写入。这远远超出了我的应用程序永远所需要的,我觉得在不影响性能的情况下使用 Properties 非常安全。
如果我错了,有人会纠正我,但我不认为 AppSettings 通常用于这些类型的配置设置。通常,您只会放入保持相当静态的设置(数据库连接字符串、文件路径等)。如果您想存储可自定义的用户设置,最好创建一个单独的首选项文件,或者最好将这些设置存储在数据库中。
appSettings 并非真正适用于您要执行的操作。
当您的 .NET 应用程序启动时,它会读入 app.config 文件,并将其内容缓存在内存中。因此,在写入 app.config 文件后,您必须以某种方式强制运行时重新解析 app.config 文件,以便它可以再次缓存设置。这是不必要的
最佳方法是使用数据库来存储您的配置设置。
除非使用数据库,否则您可以轻松设置外部 XML 配置文件。当您的应用程序启动时,您可以将其内容缓存在 NameValueCollection 对象或 HashTable 对象中。当您更改/添加设置时,您将对缓存的副本执行此操作。当您的应用程序关闭时,或在适当的时间间隔内,您可以将缓存内容写回文件。