这些值属于配置文件或数据库吗?
我在每个“模块”的 ASP.NET configSections 部分中存储了多个值。 我一直想知道它们是否属于这些文件。
背景是:这些是部署的 Web 应用程序的多个实例。 所有这些都使用相同的数据库,但有自己的设置。
我确信开发和生产之间的差异存在于配置文件中。 我知道的一些值应该包括:连接字符串、要使用的提供程序、设置调试等。
我已将所有常见部分分解到具有自己的规则和方法的类中。 剩下的部分是每个站点中每个模块的各种设置。 我不确定的一些选项包括:
- 对于 ModuleA,显示/隐藏选项
- 对于 ModuleB,该字段使用的术语是什么
- 对于 ModuleC,允许最终用户执行 X 操作
There are multiple values I have been storing in ASP.NET configSections sections for each "module". I have been wondering if they even belong in these files at all.
The background stands at: These are multiple instances of the web application deployed. All use the same database but have their own settings.
I'm sure that differences between development and production go in the config files. Some of the values I know should include: connection strings, providers to use, setting debug, etc.
I have factored out all the common pieces in to classes with their own rules and methods. The pieces left are miscellaneous settings for each module in each site. Some of the options I'm unsure of include:
- For ModuleA, Show/Hide Option
- For ModuleB, What is the terminology to be used for this field
- For ModuleC, Allow end user to perform X action
如果你对这篇内容有疑问,欢迎到本站社区发帖提问 参与讨论,获取更多帮助,或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱,如果其他用户或者作者回复了您的评论,将不能在第一时间通知您!
发布评论
评论(4)
嗯,这些听起来像是您可能希望能够在应用程序运行时更改的内容,而无需修改 app.config。 我喜欢遵循的一条经验法则是,配置中的任何内容都应该用于部署或服务器配置。 在这种情况下,您的设置似乎正在修改应用程序行为,因此如果不需要付出很多努力,我可能会将它们移至数据库中。
Mmm these sounds like things that you might want be able to change at runtime for your application without having to modify the app.config. One rule of thumb I like to follow is that anything in the config should be for the deployment or server configuration. In this case your settings appear to be modifying the application behaviour and so I would probably move them into the DB if it is not alot of effort.
ModuleA 和 ModuleC 听起来像是用户个人资料信息。 如果它们不是用户动态的,但您可以添加以后的功能,那么可以将它们移动到数据库。
我编写了一些应用程序,其中 ModuleB 也被放入数据库中。 诸如表单标签之类的东西可以轻松地放入数据库中。 如果以后有人决定向所有表单标签添加或删除冒号,那么如果所有文本都存储在数据库中,那么这是一件非常容易的事情。
ModuleA and ModuleC sound like they may be user profile information. If they're not dynamic by user, but you could add later functionality, then maybe move them to a DB.
I've written apps where ModuleB would have been put in a DB also. Things like form labels, etc. can easily go in a DB. If, at a later date, someone decides to add or remove colons to all form labels, that's a pretty easy thing to do if all of the text is stored in a DB.
考虑需要编辑其中一个值时的情况。
如果该值位于 web.config 中,则保存对该文件的更改将导致应用程序回收,从而不方便地丢弃当前用户。 如果您的应用程序位于仅在工作时间使用的内部网上,那么问题不大(尽管您可能会接到熬夜工作的人打来的愤怒电话)。 但在国际用户的公共网站上可能会出现问题。
如果该值位于数据库中,则不会以这种方式影响应用程序的处理。
无论哪种方式,请考虑这些值是否缓存在应用程序的 RAM 中(web.config 是)。 数据库值是在应用程序变量中还是在缓存中? 如果是这样,您可能不知道变化何时会发生。 除非你想重新启动应用程序。
并且,相应的管理员需要哪些不同的访问权限和权限才能进行更改? 有人必须有权访问 Web 服务器才能更改 web.config,或者必须有权访问数据库(和表)才能更改该配置。
Consider the situation when you need to edit one of the values.
If the value is in web.config, saving the change to that file will cause the app to recycle, inconveniently throwing out current users. Not so much of a problem if your app is on an intranet only used during business hours (though you could get an angry call from the guy who stayed to work late). But potentially a problem on a public website with international users.
If the value is in a database, it will have no impact on the app's processing in that way.
Either way, consider whether the values are cached in the app's RAM (web.config is). Are the database values in an Application variable, or in Cache? If so, you may not know when the change will occur. Unless you want to restart the app.
And, what different access and permissions would the appropriate admins need to make the changes? Someone would have to have access to the web server(s) to change web.config, or to the database (and table) to change that.
有几个问题:为什么对应用程序的多个实例使用相同的数据库,这将如何影响维护?
将来是否可以选择拆分数据库以提高性能? 配置模型是否比基于数据库的模型更好地支持这种更改?
换句话说,你必须考虑很多变量才能回答你的问题:-)
A few questions: Why do you use the same DB for multiple instances of the application, and how will that effect maintanence?
In the future will it be an option to split the db in order to improve performance? Does the config model support that change better then the DB based one?
In other words, you will have to consider a lot variables in order to answer your question :-)