.NET SettingsProvider/ApplicationSettingsBase 缓存
我正在查看一些使用 .NET System.Configuration.SettingsProvider 和 ApplicationSettingsBase 来处理配置的代码。
我们有一个派生自 SettingsProvider 的类，它使用数据库作为数据存储，然后我们有其他从 ApplicationSettingsBase 继承的设置类，并具有 [SettingsProvider(typeof(MySettingsProvider))] 属性。
问题是我们在多个应用程序中使用这些设置类，但它们似乎在第一次加载时永久缓存配置值。问题是，如果一个应用程序中的设置发生更改，其他应用程序在下次重新启动之前将无法获取该设置，因为它们到处都被缓存。
我的问题是：有没有办法强制 SettingsProvider 实现或从 ApplicationSettingsBase 派生的类不缓存值，并在每次访问设置时重新查询数据存储？一个有效的答案可能是这些类不适合在多应用程序环境中使用......
I'm looking at some code that uses the .NET System.Configuration.SettingsProvider and ApplicationSettingsBase to handle configuration.
We have a class that derives from SettingsProvider that uses a database as the data store, and then we have other settings classes that inherit from ApplicationSettingsBase, and have the [SettingsProvider(typeof(MySettingsProvider))] attribute.
The problem is that we're using these settings classes in multiple applications, but they seem to permanently cache the configuration values, the first time they are loaded. The issue is that if a setting is changed in one application, the other applications will not get the setting until the next restart, because they are cached everywhere.
My question is: is there a way to force the SettingsProvider implementation, or the classes derived from ApplicationSettingsBase to not cache values, and re-query the datastore every time the setting is accessed? A valid answer might be that these classes were not intended to be used in multi-application environments...
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（1）
基于 ApplicationSettingsBase 的设置对象仅在实例化、保存或重新加载操作时与持久性机制/SettingsProvider 交互。其余时间，它只是处理设置对象中的哈希表。
有几种方法可以获得您想要的行为。
首先，您可以手动实现这些不可缓存的属性，而不是依赖持久性机制。您可以在一个分部类中执行此操作，该分部类是您正常的 vs.net 生成的设置类的配套类。如果您实现了自己的设置类，则不需要分部类，并且只需附加属性即可。这种方法的缺点是每次读取该设置都会导致数据库命中。
或者，如果您需要读取缓存，但允许跨应用程序进行更改。在可以覆盖的 ApplicationSetttingsBase.Save 中，您可以使用发布/订阅者机制，该机制允许您通知所有订阅者通过 ApplicationSetttingsBase.Reload 刷新其内容。
这涉及更多，并且根据要求，您可能需要担心保持设置对象的状态一致。
Settings objects based on ApplicationSettingsBase only interact with the persistence mechanism/SettingsProvider on instantiation, Save or Reload operations. The rest of the time, it's just working off the hashtables in the settings object.
There's a few ways to get the behaviour that you want.
First, you could implement those non-cacheable properties manually, rather than rely on the persistence mechanism. You can do this in a partial class that is a companion to your normal vs.net generated settings class. If you implemented your own settings class, you don't need the partial class, and you can just tack on the property. The drawback of this approach is that every read on that setting, will incur a db hit.
Alternatively, if you need read caching, yet allow for change across applications. In ApplicationSetttingsBase.Save, which you can override, you could use a publish/subscriber mechanism that allows you to notify all the subscribers to refresh their through ApplicationSetttingsBase.Reload.
This is much more involved, and depending on requirements, you may need to worry about keeping the state of your settings objects consistent.