通用 Web 应用程序“功能”的最佳方法/ 全局属性
我正在创建一个通用的灵活网站,我可以反复使用它,但可以激活或停用不同的功能。我正在寻找实现我的解决方案的最佳方法。
在某些情况下,特定区域需要关闭,例如,应用程序将包含事件管理页面,但并不总是需要。该应用程序将从数据源中提取活动和停用的功能。
它们将类似于应用程序范围的设置,每个页面都需要这些设置,隐藏那些从菜单中关闭的设置,并且不允许用户访问已停用的功能页面。
我想了很多方法来实现这一点:
- 将功能状态存储在数据库中,然后在每次访问/显示页面/菜单时,调用数据库请求是否隐藏页面/菜单项。
- 将功能状态存储在数据库中并在应用程序启动时访问它们,将它们存储在应用程序范围内,然后可以随时访问它们。
- 将功能状态放入 Web 配置中,这样我们就不需要每次都查询数据库或具有全局可访问的属性。
我希望您建议哪种方法最好,或者如果有更好的方法可用,我将不胜感激。我不想多次访问数据库,或者像这样的简单检查不会太耗费性能吗?我也不确定网络配置是否足够安全来管理活动站点功能。
问候,
I'm creating a generic flexible site that I can use over and over again but with different features activated or deactivated. I'm looking for the best method to approach my solution.
Specific areas will need to be closed off in certain circumstances, for instance, the application will contain an event management page, but it will not always be required. The application will pull out the active and deactivated features from a data source.
They're going to be like Application wide settings, that will be required on each page, hiding away those settings that are turned off from the menu and not allowing users to access the deactivated feature pages.
I have thought of a number of ways to achieve this :
- Store the feature statuses in the database, then on each time the page / menu is accessed / displayed, call the database requesting whether to hide the page / menu item.
- Store the feature statuses in the database and access them on the application startup, store them application wide then they can be accessed as and when.
- Put the feature statuses in the web config, this way we don't need to query the database every single time or have globally accessible properties.
I would like you advice on which method would be best, or if a better method is available I would be grateful. I don't want to hit the database too many times, or would a simple check like this not be too performance expensive? I'm also not sure if the web config is secure enough for managing active site features.
Regards,
如果你对这篇内容有疑问,欢迎到本站社区发帖提问 参与讨论,获取更多帮助,或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱,如果其他用户或者作者回复了您的评论,将不能在第一时间通知您!
发布评论
评论(3)
我认为将配置放在配置文件(web.config)中是更好的选择。因为在显示页面/加载菜单时,每次都会去数据库查看它是否应该停用/活动,需要数据库访问,这是开销。
如果配置存储在 web.config 中,则管理员可以轻松访问它,并且无需编译或更改任何内容即可轻松修改。
因此,在我看来,最好的选择是将配置存储在 web.config 中。除此之外,您还可以创建管理页面,该页面将更改配置设置并应反映在配置文件中。
I think putting configuration in configuration file(web.config) would be better option. Because while displaying page/loading menu going to database every time to see whether it should be de/active, required database trip which is overhead.
And if the configuration is stored in web.config it is easily accessible by admin and also easy to modify without compiling or changing anything.
So, in my view best option is to store configuration in web.config. In addition to that you can also make administration page which will change configuration settings and should be reflected in configuration file.
我建议第二种方法 - 将设置存储在数据库中,然后在启动时检索它们并存储在应用程序范围的容器中。
与
web.config
相比,这种方法的优点是您可以轻松获取客户端数据库并立即在开发环境中运行它以进行测试/调试。另一方面,如果某些设置存储在数据库外部,则克隆站点意味着您不仅需要克隆数据库,还需要克隆来自各种其他资源(例如web.config)。
I suggest 2nd approach - store the settings in the database and then retrieve them at startup and store in application scoped containers.
The advantage of such approach over the
web.config
is that you can easily take client database and immediately run it in your development environment for testing/debugging. If, on the other hand, some settings are stored outside of the database, cloning the site means that you not only have to clone the database but also all the settings from various other resources (like theweb.config
).答案取决于您更改功能状态的频率。
如果您只想在克隆站点时设置状态一次并且再也不会触及它,请选择选项#2(在应用程序启动时加载)。
如果您将来有可能需要更改功能的状态,请选择选项#1(获取每个页面加载的状态)。读取数据库的简单数据读取器不会影响站点的速度。数据库是你的朋友,记住这就是它的用途。此外,如果您需要在站点启动并运行时更改状态,此方法允许您无需重新启动整个应用程序即可执行此操作。
无论您最终决定实现什么方法,请确保您存储设置的“应用程序范围”位置已准备好进行多线程处理。请记住,每个页面请求都将在单独的线程上运行,并且它们都将访问相同的资源。
我的建议来自 MS(多线程安全单例模式):
The answer depends on how often you will be changing the status of the features.
If you are going to only set the statuses once when you clone the site and will never touch it again, go with option #2 (load on application start).
If there is any possibility that you will need to change the status of the features in the future, go with option #1 (get statuses on each page load). A simple datareader read to the db will not affect the speed of your site. The db is your friend, remember that's what it is there for. Also, if you ever need to change the statuses while the site is up and running, this method allows you to do so without restarting the entire application.
Whatever method you finally decide to implement, make sure the "application wide" location you store the settings is multi-threaded ready. Remember, each page request will be run on a separate thread and they will all access the same resource.
My suggestion taken from MS (multi-thread safe Singleton Pattern):