2008-08-07 108 views
20

我打算将我的所有配置设置存储在应用程序的app.config部分(使用ConfigurationManager.AppSettings类)。当用户使用应用程序的UI更改设置(单击复选框,选择单选按钮等)时,我打算将这些更改写入AppSettings。与此同时,在程序运行时,我打算不断地从一个不断处理数据的进程中访问AppSettings。通过用户界面对设置进行的更改需要实时影响数据处理,这就是为什么该过程将持续访问AppSettingsConfigurationManager.AppSettings性能问题

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

如果有人有这方面的经验,我会非常感激的输入。

更新:我应该澄清几点。

这不是一个Web应用程序,因此将数据库连接到应用程序可能会过度简单地用于存储配置设置。这是一个Windows窗体应用程序。

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

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

只是为了验证它实际上能够处理我需要的负载,我在我的笔记本电脑上做了一些测试,并且能够使用属性每秒执行750,000次读取和7,500次写入。这是远远超出我的应用程序将有史以来甚至接近需要我觉得使用属性相当安全,而不影响性能。

回答

8

因为您使用的是winforms应用程序,如果它在.net 2.0中,实际上有一个专门用于此目的的用户设置系统(称为属性)。 This article on MSDN对此有一个很好的介绍

如果你仍然担心性能,那么看看SQL Compact Edition这与SQLite类似,但是我发现微软提供的与winforms搭配非常好,甚至还有能力make it work with Linq

1

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

0

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

通常,我会保存appSettings部分中很少更改的应用程序设置(默认的电子邮件地址错误日志发送到,自动注销的分钟数等等)。真正的范围处于应用程序中,而不是用户处,通常用于部署设置。

0

我想要做的一件事就是在读取上缓存appsettings,然后在写入时从缓存中清除设置,以尽量减少服务器处理appSettings所需的实际负载量。

此外,如果可能,请考虑打破应用程序设置为configSections,以便您可以读取写入和缓存相关设置。

说了这么多,我会认真考虑将这些值存储在数据库中,因为您似乎实际上正在存储用户首选项,而不是应用程序设置。

2

检出SQLite,它似乎是这种特殊情况的一个很好的选择。

1

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

2

迪伦,

不要使用应用程序配置文件用于此目的,使用SQL数据库(SQLite的,MySQL和MSSQL,无论),因为你必须期间少担心并发问题读写配置文件。

您还可以在要存储的数据类型中拥有更好的灵活性。 appSettings部分只是一个键/值列表,随着时间的推移和应用程序的成熟,您可能会长大。您可以使用自定义配置部分,但是当涉及到设计时,则会进入新的问题区域。

2

appSettings并不是真正意义上的你想要做的。

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

最好的办法是使用数据库来存储配置设置。

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