HTTPHandler 与 .aspx
使用 HTTPHandler 与 .aspx 相比有何优点？它是否具有相同的功能，并且重量更轻、速度更快？
有哪些缺点？
What are the advantages of using an HTTPHandler vs an .aspx? Does it have the same capabilities and is it lighter weight and faster?
What are some of the disadvantages?
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（4）
Aspx 使用具有复杂页面生命周期和大量附加处理的全功能 Web 表单。 HttpHandler 是纯粹且轻量级的。它仅具有您实现的功能。
Aspx uses full power Web form with complex page life cycle and a lot of additional processing. HttpHandler is pure and lightweight. It has only functionality you implement.
请记住，当您的 .aspx 页面被编译时，它将被转换为直接或间接派生自
System.Web.UI.Page的类（通过继承自“代码隐藏”类，该类依次直接或间接继承自Page实现
IHttpHandler，因此您永远不会不使用IHttpHandler。 >快速浏览一下
Page的成员列表就可以找到这个问题的答案。有很多事情正在发生，并且提供了很多派生类（即 .aspx 文件和）。这是在我们考虑如何解析 .aspx 文件以使得编写包含大量“模板”代码的代码变得非常容易之前，如果您编写自己的处理程序，那么您将失去所有这些。您可以提高性能，但没有您想象的那么多，如果不使用它，也不会花费很多。事实上，如果您确实丢失了所需的东西，您自己找回它的方法可能会效率较低。
如果编写有问题的处理程序的自然方法是让所有事情直接或间接地从代码隐藏中的单个事件处理程序发生（方法调用），并且使用空的 .aspx，那么将其编写为更清楚相反，在这种情况下可以使用处理程序。否则，您想坚持使用 .aspx 文件。
Remember that when your .aspx page is compiled, it will be turned into a class that derives from
System.Web.UI.Pagewhether directly or indirectly (by inheritting from a "code-behind" class that in turn is either directly or indirectly inheritted fromPage.PageimplementsIHttpHandler, so you're never not usingIHttpHandler.And a quick scan at the member list of
Pagegives its own good answer to this question. There's a lot going on, and a lot offered to deriving classes (that is, to .aspx files and to code behinds). And that's before we consider the way .aspx files are parsed to make writing code with large amounts of "template" code in them very easy.You lose all of that if you write your own handler. Losing it will give you a performance boost, but not as much as you might think, a lot doesn't cost if it isn't used. Indeed, if you do lose stuff you need, your own methods of getting it back may well be less efficient.
If the natural way to write the handler in question would be to have everything happen directly or indirectly (method call) from a single event handler in your code-behind, and with an empty .aspx, then it may be clearer to write it as a handler instead, in which case do. Otherwise, you want to stick with the .aspx file.
通过 .aspx，您实际上指的是 System.Web.UI.Page 的实例，正如您在该类的元信息中看到的那样，它是 IHttpHandler 的实现 - 换句话说（粗略地说）Page 实例是< /em> 一个 HttpHandler （这才是重点）加上一大堆赋予它页面行为的东西。
因此，不同之处在于，使用 Page 可以利用它提供的所有功能（视图状态、控制性、生命周期等），但代价是无论您是否需要它，都必须承担所有这些开销与否，与编写自己的实现相比，您可以使其轻量级并适合您选择的目的，但代价是必须自己编写所有内容。
因此，当您对页面支持不感兴趣时，HttpHandler 特别合适，因为您没有提供语义页面响应 - 使用页面提供 XML、JSON、图像或除 HTML 样式标记之外的任何内容几乎肯定是错误的。
在实践中，我大多数时候选择第三个选项 - MVC :)
By .aspx you really mean an instance of System.Web.UI.Page which as you can see in the meta-information for that class is an implementation of IHttpHandler - in other words (roughly speaking) a Page instance is an HttpHandler (this is rather the point) plus a whole bunch of stuff which gives it Page behaviour.
The difference therefore, is that using Page you can leverage all of the things it gives you (viewstate, control-ness, a life cycle, etc..) at the cost of having to have all of that overhead regardless of whther you need it or not, vs writing your own implementation where you can make it as lightweight and fit for purpose as you choose at the cost of having to write it all yourself.
HttpHandler is therefore particularly appropriate when you're not interested in Page support because you aren't delivering a semantic page response - it is almost certainly a mistake to deliver XML, JSON, images, or anything but HTML style mark-up with a Page.
In practice, I choose a third option - MVC - most of the time :)
根据页面/处理程序正在执行的操作，我使用普通处理程序而不是页面获得了 5 到 15% 的性能提升 - 它们通常是生成图像、json 等、处理来自 ajax 请求的后台任务或执行以下操作的不错选择诸如通过图像请求进行访客记录之类的事情。
如果您编写大量 html，则使用处理程序会有点痛苦 - 构建 html 字符串时出现错误的可能性通常超过了性能优势。
使用处理程序会丢失的一件重要的事情是使用输出缓存声明进行简单的缓存 - 您当然可以自己以编程方式连接它，但我发现 aspnet 通常在缓存管理方面比我快速编写的任何内容都做得更好。
Depending on what the page / handler is doing, I have had between 5 to 15% performance boost using plain handlers instead of pages - they are often a good choice for generating images, json, etc, handling background tasks from ajax requests, or doing things like visitor logging from image requests.
Handlers are a bit painful to use if you a writing out a lot of html - the potential for errors building up strings of html often outweighs the performance benefits.
One significant thing that you lose with a handler is no-brainer caching with the ouput cache declaration - you can of course wire it up yourself programatically, but I have found that aspnet usually does a better job of cache management than anything I write quickly.