我计划将所有配置设置存储在应用程序的 app.config 部分中(使用 ConfigurationManager.AppSettings 班级)。当用户使用应用程序的 UI 更改设置(单击复选框、选择单选按钮等)时,我计划将这些更改写入 AppSettings. 。同时,当程序运行时,我计划访问 AppSettings 不断地从不断处理数据的过程中产生。通过 UI 更改设置需要实时影响数据处理,这就是进程将访问 AppSettings 不断地。

就性能而言,这是一个好主意吗?使用 AppSettings 应该是编写 .Net 应用程序时存储和访问配置设置的“正确方法”,但我担心此方法不适用于恒定负载(至少在不断读取的设置方面)。

如果有人有这方面的经验,我将不胜感激。

更新: 我也许应该澄清几点。

这不是一个 Web 应用程序,因此将数据库连接到应用程序可能只是为了存储配置设置而太过分了。这是一个 Windows 窗体应用程序。

根据 MSDN 文档, ConfigurationManager 不仅用于存储应用程序级别设置,还用于存储用户设置。(例如,如果应用程序作为部分信任应用程序安装,则尤其重要。)

更新2: 我接受了 lomaxx 的回答,因为 Properties 确实看起来是一个很好的解决方案,无需向我的应用程序添加任何额外的层(例如数据库)。当使用 Properties 时,它已经完成了其他人建议的所有缓存。这意味着任何更改和后续读取都在内存中完成,使其速度非常快。仅当您明确告知属性时,属性才会将更改写入磁盘。这意味着我可以在运行时动态更改配置设置,然后仅在程序退出时最终保存到磁盘。

为了验证它实际上能够处理我需要的负载,我在我的笔记本电脑上做了一些测试,并且能够使用 Properties 每秒执行 750,000 次读取和 7,500 次写入。这远远超出了我的申请的范围 曾经 甚至接近需要我觉得使用属性非常安全而不影响性能。

有帮助吗?

解决方案

由于您使用的是 winforms 应用程序,如果它在 .net 2.0 中,实际上有一个用户设置系统(称为“属性”)就是为此目的而设计的。 MSDN 上的这篇文章 有一个很好的介绍

如果您仍然担心性能,请查看 SQL 精简版 它与 SQLite 类似,但我发现它是 Microsoft 的产品,与 winforms 配合得非常好,甚至还能够 让它与 Linq 一起工作

其他提示

查看 SQLite,对于这个特定场景来说它似乎是一个不错的选择。

迪伦,

不要将应用程序配置文件用于此目的,而应使用 SQL DB(SQLite、MySQL、MSSQL 等),因为您不必担心读取和写入配置文件期间的并发问题。

您还可以更灵活地选择要存储的数据类型。appSettings 部分只是一个键/值列表,随着时间的推移和应用程序的成熟,您可能会不再需要它。您可以使用自定义配置部分,但在设计方面您会遇到一个新的问题领域。

appSettings 并不是真正适合您想要做的事情。

当您的 .NET 应用程序启动时,它会读取 app.config 文件,并将其内容缓存在内存中。因此,在写入 app.config 文件后,您必须以某种方式强制运行时重新解析 app.config 文件,以便它可以再次缓存设置。这是不必要的

最佳方法 将使用数据库来存储您的配置设置。

除非使用数据库,否则您可以轻松设置外部 XML 配置文件。当应用程序启动时,您可以将其内容缓存在 NameValueCollection 对象或 HashTable 对象中。当您更改/添加设置时,您将对缓存的副本执行此操作。当您的应用程序关闭时,或在适当的时间间隔,您可以将缓存内容写回到文件中。

如果我错了,有人会纠正我,但我不认为 AppSettings 通常用于这些类型的配置设置。通常,您只会放入保持相当静态的设置(数据库连接字符串、文件路径等)。如果您想存储可自定义的用户设置,最好创建一个单独的首选项文件,或者最好将这些设置存储在数据库中。

我不会使用配置文件来存储用户数据。使用数据库。

请问为什么不将用户的设置保存在数据库中?

通常,我将不经常更改的应用程序设置保存在 appSettings 部分中(发送默认电子邮件地址错误日志、自动注销的分钟数等)。其范围实际上是在应用程序中,不在用户处,通常用于部署设置。

我会考虑做的一件事是在读取时缓存应用程序设置,然后在写入时从缓存中刷新设置,这应该最大限度地减少服务器处理应用程序设置时必须处理的实际负载量。

另外,如果可能的话,考虑将 appSettings 分解为 配置部分 这样您就可以读取写入和缓存相关设置。

话虽如此,我会认真考虑将这些值存储在数据库中,因为您似乎实际上正在存储 用户偏好, ,而不是应用程序设置。

许可以下: CC-BY-SA归因
不隶属于 StackOverflow
scroll top