【问题标题】:Should ASP.NET AJAX be avoided in heavy pages?是否应该在重页中避免使用 ASP.NET AJAX?
【发布时间】:2009-09-28 04:48:49
【问题描述】:

我只为某些用户收到一些 js 错误,而且只是偶尔在使用大量 ASP.NET AJAX 的页面上。

该页面还执行一些密集的 SQL 查询和一些字符串操作以突出显示在搜索结果中找到的文本。

这可能是性能的结果吗?在苛刻的情况下使用 ASP.NET AJAX 是否总是安全的,还是应该寻找其他 AJAX 技术?

(顺便说一下,我有时看到的错误是):

消息:Sys.WebForms.PageRequestManagerServerErrorException:处理服务器上的请求时发生未知错误。服务器返回的状态码为:12031

消息:Sys.WebForms.PageRequestManagerParserErrorException:无法解析从服务器接收到的消息。此错误的常见原因是通过调用 Response.Write()、响应过滤器、HttpModules 或启用了服务器跟踪来修改响应。 详细信息:在“ ”附近解析出错。

【问题讨论】:

    标签: performance exception asp.net-ajax


    【解决方案1】:

    众所周知,ASP.NET AJAX 不是性能最密集的方法,但我想这就是你得到的,以换取它的实现有多简单。

    我知道您不允许在更新面板中执行任何 Response.Writes。这将导致您的第二个错误。

    【讨论】:

    • 是的:Response.Write() 与 document.write 做同样的事情,它会清除整个页面并开始新文档。
    【解决方案2】:

    这个特殊的例外是非常 常见的,可能是由任何一种引起的 以下:

    1.调用 Response.Write(): 通过直接调用 Response.Write() 你绕过了正常的 ASP.NET的渲染机制 控制。你写的位正在 直接发给客户 进一步处理(嗯,主要是......)。 这意味着 UpdatePanel 不能 以特殊格式对数据进行编码。

    2。响应过滤器: 与 Response.Write() 类似,响应过滤器可以更改 以这样的方式呈现 UpdatePanel 不会知道。

    3. HttpModules: 同样,与 Response.Write() 和响应过滤器的处理相同。

    4.服务器跟踪已启用: 如果我要再次实施跟踪,我会采取不同的做法。 跟踪有效地写出使用 Response.Write(),以及这样的混乱 我们使用的特殊格式 更新面板。

    5.调用 Server.Transfer(): 不幸的是,没有办法检测到 Server.Transfer() 是 叫。这意味着更新面板 不能做任何聪明的事 有人调用 Server.Transfer()。这 发送回客户端的响应是 来自页面的 HTML 标记 你转移了。由于它的 HTML 和 不是特殊格式,不可能 解析,你得到错误。

    完成帖子: ASP.NET AJAX and Sys.Webforms.PageRequestManagerServerErrorException

    您可以使用 Visual Studio 调试功能获取导致错误的代码。我知道的不多,但也许它会有所帮助,而且 Firebug 会帮助您查看服务器响应和您提交给服务器的数据。

    这是一个视频,您可以在其中了解如何使用 Firebug 调试 Ajax。 See how I used Firebug to learn jQuery

    但我认为在重载页面中不应该避免使用 Asp.NET Ajax。这实际上就是 Ajax 的含义吗?我的意思是它还减轻了服务器发送小块页面而不是再次请求整个页面的负担。

    【讨论】:

      猜你喜欢
      • 2016-03-26
      • 2010-10-24
      • 2011-10-19
      • 1970-01-01
      • 2016-03-16
      • 2020-05-22
      • 2014-10-15
      • 1970-01-01
      • 1970-01-01
      相关资源
      最近更新 更多