ASP.NET WebForms -- 在站点上的所有页面上处理特殊的查询字符串参数 -- URL 重写、URL 路由或其他方法?
在一个将与第三方供应商集成的电子商务网站上工作 - 该供应商使用的商店标识符与我们内部使用的不同(即他们的商店 ABC123 是我们的 001-321)。
我正在研究检查传入请求中保留查询字符串参数的最佳方法,这些参数指示请求正在使用他们的标识符并将标识符映射回我们的标识符(因此,如果请求是 example.com/ &theirId=ABC123 我想将请求转换为 example.com/&ourId=001-321)。
要执行此映射,我需要检查提供的 ID,对数据库或缓存执行查找,并将请求转发到指定页面 - 将修改限制为仅查询字符串参数(需要维护其他参数,如 HTTPHeader 的详细信息等)。
到目前为止,我正在研究几种不同的方法:
- 在基页面中实现它(它已经做了太多的事情,但有我们的日志基础设施和其他一些注入依赖项的好处)
- 在 IHttpModule 中实现它
- 使用 URL 重写
Using URL 路由(看起来路由不是我想要的,如果您认为它仍然合适,请随时提供见解)
性能成本是一个考虑因素:此翻译的实际次数与不需要它的请求数量相比,发生的请求数量非常小——可能为 1%。
但是对于另一个集成站点,我们将针对几乎每个请求执行此映射 - 与之前不同的方法是否会更适合此场景?
Working on an ecommerce site which will be integrated with a 3rd party vendor--that vendor uses different identifiers for stores than we use internally (i.e. their store ABC123 is our 001-321).
I'm researching the best approach to inspect incoming requests for reserved query-string parameters that indicate the request is using their identifiers and map the identifiers back to our identifiers (so if the request is example.com/&theirId=ABC123 I want to transform the request to example.com/&ourId=001-321).
To do this mapping I need to inspect the provided ID, execute a lookup against the database or cache, and forward the request to the specified page--limiting the modifications to just the query-string parameters (other parameters will need to be maintained, as with the details of the HTTPHeader, etc).
So far I'm researching a few different approaches:
- Implementing it in a base Page (which already does too much, but has the benefit of our Logging infrastructure and some other injected dependencies)
- Implementing it in an IHttpModule
- Using URL Rewriting
Using URL Routing(looks like routing isn't what I want, feel free to offer insight if you think it still fits)
Performance cost is a consideration: the actual number of times this translation will occur will be very small compared to the number of requests not requiring it--perhaps 1%.
However for another integrated site we will perform this mapping on nearly every request--would a different approach be better suited to this scenario from the previous?
如果你对这篇内容有疑问,欢迎到本站社区发帖提问 参与讨论,获取更多帮助,或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱,如果其他用户或者作者回复了您的评论,将不能在第一时间通知您!
发布评论
评论(3)
这是一个典型的案例,其中 HTTP 模块最有意义——您希望深入研究所有请求的 URL 处理。从性能角度来看,假设您可以正确地短路并避免在不需要的地方进行数据库/缓存查找,那么您不应该有那么多问题。
在配置方面,您应该已经解决了部署和管理配置的问题,因此我怀疑另一个自定义模块是否会增加太多开销。
就代码而言,通常更倾向于组合而不是继承——您可以根据需要添加或删除模块——但是将代码静态地包含到臃肿的基页类中可能会带来更多挑战。
This is a classic case where a HTTP module makes the most sense--you wish to dive into the URL handling on all requests. Perf-overhead-wise you shouldn't have that much of an issue presuming you can short-circuit things correctly and avoid doing DB/cache lookups where you don't need.
Configuration-wise, you should already have to solve the problem of deploying and managing your configuration, so I doubt if another custom module adds much overhead.
Code-wise, its generally better to favor composition over inheritance--you can add or remove the module as required--but having code statically included into a bloated base page class can create more challenges.
我已经实现了与此类似的东西作为我的 aspx 页面的基页面类,但正如您提到的,模块也可以工作。在我看来,如果所有页面都需要此功能,我只会创建一个基类,因为维护另一个 http 模块更加痛苦,因为它需要映射到您的 Web 配置/iis 中。 URL 重写是 CPU 密集型的,可能无法为您提供所需的灵活性 - 同样,它只是添加了另一个配置/ISS 依赖项。我认为只要您实现某种缓存,这些都不会产生太多开销。
希望这会有所帮助...
享受吧!
I have implemented something similar to this as a base page class for my aspx pages, but as you mentioned a module would work as well. In my opinion, if this functionality is needed across all pages I would just crate a base class only because maintaining another http-module is more of a pain because it needs to be mapped in your web config / iis. Url rewriting is cpu intensive and may not provide you the flexibility you need - again it just adds another configuration / iss dependency. I don't think either of these are going to incur much overhead as long as you implement some sort of caching.
Hope this helps...
Enjoy!
我通常创建一个 Singleton 类来保存站点的请求上下文,并将其存储在 HttpContext.Current.Items() 中。我在 Application_BeginRequest 例程中初始化此类。
公共类 SiteContext
结束类
I usually create a Singleton class to hold the site's request context, and store it in the HttpContext.Current.Items(). I initialize this class in the Application_BeginRequest routine.
Public Class SiteContext
End Class