使用数据库保存应用程序设置
我正在寻找使我们的应用程序更具可扩展性和更易于操作的方法，而无需更改 web.config （或者，在我们的例子中，是包含 appsettings 节点的 application.config 文件）。
我考虑过的一种方法是将应用程序设置保留在具有 sqlcachedependency 的数据库表中。这意味着：
- 每当数据库中的设置发生更改时，缓存就会失效，并再次检索设置，从而实时更新应用程序，而无需更改文件并重新启动整个应用程序。
- 我们可以创建一个自定义工具来更改设置。
我认为的缺点是，这可能会导致严重的逻辑问题，因为如果您有一些东西可以在流程开始时检查应用程序设置，然后它在中途发生变化，您最终可能会无意中改变流程，如无需重新启动完整的应用程序。
有办法解决这个问题吗？
是否有更好的方法来管理应用程序设置，以便您可以一次性远程远程更改一台、几台或所有服务器的应用程序设置？
I am looking at ways to make our application more extensible and easier to manipulate without having to alter the web.config (or, in our case, application.config files, which contain the appsettings node).
One way I have thought about is keeping the app settings in the database table that has a sqlcachedependancy. This means that:
- Any time a setting is changed in the database, the cache is invalidated, and the settings are retrieved again, thus updating the application in realtime without having to alter files and restart the entire app.
- We can create a custom tool which allows us to alter the settings.
The cons as I see it are that this may cause serious logic problems in that, if you have something that checks an appsetting at the start of a process, and it then changes halfway through, you could end up unintentionally altering the process flow, as the requirement for a complete application restart is negated.
Is there a way round this?
Is there a better way to manage appsettings, so that you can alter them on the fly remotely for one, several, or all servers in one go?
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（3）
我认为您已经确定了两个主要参与者：
要么：
这两种方法都有其优点和缺点。我长期以来一直在尝试找到一种从数据库字段“具体化”配置部分的方法，这样我基本上就可以使用配置 XML，但存储在数据库字段中。不幸的是，整个 .NET 2.0 配置系统在很大程度上被“锁定”，并且仅假设数据来自文件 - 无法插入数据库提供程序以允许配置系统从数据库字段读取其内容： -( 真的太糟糕了！
我见过的唯一其他方法是 StockTrader 2.0 示例应用程序 由 Microsoft 提供，但对于我的需求来说，它感觉有点大材小用，就像一个非常复杂、非常重量级的子系统。
I think you've nailed the two major players:
OR:
Both approaches have their pros and cons. I've been trying for a long time to find a way to "materialize" a config section from a database field, so that I could basically just use the config XML, but stored in a database field. Unfortunately, the entire .NET 2.0 config system is very much "locked down" and just only assumes data will come from files - there's no way to plug in e.g. a database provider to allow the config system to read its contents from a database field :-( Really too bad!
The only other approach I've seen is a "ConfigurationService" in the StockTrader 2.0 sample app provided by Microsoft, but for my needs, it felt like overkill and like a really complex, really heavy-weight subsystem.
您可以使用SQLite，它将是单个文件中的独立数据库。一石二鸟？
You could use SQLite, which will be a self-contained DB in a single file. Two birds with one stone?
如果您引用包含 appsettings 的外部配置文件（将其他所有内容保留在正常的 app.config 中），那么我相信编辑它只会重新加载这些设置，而不会强制整个应用程序重新启动。
这里有一个关于这个主题的类似问题：
嵌套 app.config (web.config) 文件
WRT值更改的问题在程序执行过程中，我想您可以在本地缓存这些值，并在它们更改时引发一个事件，从而允许例程在使用更新的值之前到达合适的点。
我认为在 ASP.NET 中，我们可以免费获得此值，因为每个页面生命周期都是不同的，因此该值仅应用于新页面请求，而不是在执行过程中。
编辑：一点额外的信息：
配置更改导致应用程序域重新启动
MSDN ：
有关 ConfigurationManager 类 的详细信息，位于 System.Configuration 命名空间 可用于以编程方式修改配置文件（即在自定义工具中，是否可以提供相关的磁盘读取权限）。如果您坚持使用内置配置类，我认为更改外部配置不会导致应用程序重新启动，但会引发事件（例如 属性已更改），您可以处理它，以确保您的代码不会因更改设置而被捕获。
If you reference an external config file that contains appsettings (leaving everything else in the normal app.config) then I believe editing it only reloads those settings, it doesn't force the whole app to restart.
There's a similar question on the subject here:
Nested app.config (web.config) files
WRT the problem of values changing in the middle of program execution, I guess you could locally cache the values, and raise an event when they change, allowing routines to reach a suitable point before using the updated values.
I think in asp.net we sort of get this for free because each page lifecyle is distinct, so the value is simply applied to new page requests only, not in the middle of an execution.
Edit: A little extra info:
Configuration Changes Cause a Restart of the Application Domain
From MSDN:
More information on the ConfigurationManager class in the System.Configuration namespace which could be used to modify the config files programatically (ie in a custom tool, if relevant disk read permissions can be provided). If you stick to using the built in configuration classes, I think changing the external configs, would not cause application restart, but would raise events (such as property changed) which you could handle, to ensure your code is not caught out by changing settings.