ASP.Net MVC 3 中处理 Ajax 调用的正确方法

Question

当在 ASP.Net MVC 中编码 Ajax 调用时，我们有很多选择来发出调用、在服务器上处理它们以及在客户端上处理成功和失败。有些事情显然有正确的答案，但我一直无法找到明确的指导。那么，端到端的ajax调用的正确方法是什么？

包括

• 将url的action的url注入ajax调用的最佳方式是什么？
• 选择JsonBehavior时有哪些考虑因素？
• 在服务器端处理错误的最佳方法是什么？
  • 客户端 error() 回调应该由任何错误（即意外的 OutOfMemoryException）触发，还是仅由可预见的错误（即无效输入）触发？
  • 以触发 error() 回调的方式导出错误的最佳方式是什么。
  • 确保错误回调获取正确状态代码和响应文本的最佳方法。
  • 验证错误是否会导致错误状态代码，或者它们是否应该成为响应验证对象的一部分。
• 在客户端处理错误的最佳方法是什么？
  • 服务器端意外错误是否应该以与验证摘要类似的方式显示？也许只是一个“出了问题”的对话框？客户应该能够区分两者吗？

人们对其他事情有强烈的看法吗？

Answer 1

问题/回答风格

将 URL 操作的 URL 注入 Ajax 调用的最佳方式是什么？
这方面没有惯例，而且很大程度上取决于您的内容如何呈现给客户。是通过视图/部分视图（在这种情况下，您可以使用 Html/Url 辅助方法生成 URL，还是纯粹在客户端生成（模板等）。它是很常见的是，我们只希望使用 Ajax 行为扩展一些常见的 HTML 元素（例如表单、按钮和链接），在这种情况下，最好提供正确的 URL，我们也可以从中读取这些 URL 并在脚本中使用它们（例如 href 链接）。对于用户来说，我们是否将它们转换为 GET/POST/DELETE/PUT 请求并不重要。在脚本中对 URL 进行编码，因为您可能会更改路由或提供其他处理方式，在维护方面，尽可能使用 Html 帮助程序是更好的方法。它们会自动（没有 href 或 src 属性），您始终可以将它们添加为自定义属性，特别是当您使用数据属性（例如 data-href 或相似的）。阅读John Resig 的博客文章了解这些内容。

选择JsonBehavior有哪些考虑因素？
当必须返回Json时最好发出POST请求。在 GET 请求中，您必须了解可能的影响 JSON 劫持< /a> 这也是您必须明确指定允许带有 JSON 结果的 get 请求的原因。

在服务器端处理错误的最佳方法是什么？
处理服务器错误（不能也不应该被抑制）的最佳方法是实际通知用户错误。它的细节通常并不重要，因为用户不熟悉开发，但告诉他们出了问题是可以的。特别是如果你可以为他们提供某种解决方案。通过 Ajax 调用，可以将错误返回为可以使用错误处理程序 Javascript 函数处理的错误。我写了一篇博客文章，详细介绍了整个过程提供显示如何正确处理验证错误的代码。我个人认为将错误返回为成功是错误的。因此我不这样做。但这是有争议的。我使用的代码相当简化了我的控制器操作：

[HandleModelStateException]
public ActionResult AddUser(User user)
{
    if (!this.ModelState.IsValid)
    {
        throw new ModelStateException(this.ModelState);
    }
    // process valid data
}

客户端 error() 回调应该由任何错误（即意外的 OutOfMemoryException ）触发，还是仅由可预见的错误（即无效输入）触发）？
如前所述，当用户从其发起的操作中获得意外结果时，应向用户报告错误。不要隐瞒应该向他们报告的错误。但不要讨论太多细节。内存不足异常对于普通计算机用户来说有点太复杂了。报告一些人性化且简短的内容。

以触发 error() 回调的方式导出错误的最佳方式是什么。
查看我的博客文章并检查代码以了解如何创建由 error() 函数处理的错误

确保错误回调获取正确状态代码和响应文本的最佳方法。
相同博客文章

验证错误是否会导致错误< code>StatusCode 或者它们应该是响应验证对象的一部分。
验证错误实际上本质上是警告，应该这样对待。这就是为什么您可以在某些网站上看到肯定的表单验证模式，这些网站还会报告数据何时有效，而不仅仅是通知用户他们又犯了另一个错误。验证错误通常源于无效的用户界面体验和信息不足。

在客户端处理错误的最佳方法是什么？
这很大程度上取决于您的应用程序，但我建议您遵循经过验证的模式，因为用户可能知道该怎么做并且不会混淆。您认为为什么 OpenOffice 使用与 Microsoft Office 几乎相同的 UI？因为用户知道它是如何工作的，所以更有可能快速、轻松地熟悉该应用程序。但如果可以的话，不要把用户当作傻子。使用积极的验证。有些错误也应该显示为错误。哦。顺便提一句。我在我的应用程序中使用不引人注目的信息，其中向用户报告成功操作等信息，但不会干扰他们的工作。一段时间后它会自动消失。与 GMail 的做法类似。它只是通知您邮件已发送，并且此信息不需要任何确认。
jQuery ajax() 函数支持成功和错误函数，因此使用这两个函数是明智的。再次强调：将错误视为成功是不对的。我们根本不需要误差函数。我的 HandleModelState 操作过滤器返回带有可以使用的特定 400 错误代码的错误及其结果。

$.ajax({
    url: $(this).attr("href"),
    data: someDataObj,
    type: "POST",
    success: function(data){
        // process data
    },
    error: function(xhr, status, err){
        if (xhr.status = 400) {
            // handle my error in xhr.resposeText
        }
        else {
            // handle other errors that are cause by unknown processing
        }
    }
});

服务器端意外错误是否应该以与验证摘要类似的方式显示？也许只是一个“出了问题”对话框？客户应该能够区分两者吗？
人们不喜欢大红色警报。如果某些内容本质上是警告，则应该比阻止应用程序正常运行的实际错误更友好地对待它。验证尤其应该非常友好。错误应该由用户确认，警告可能不应该。取决于他们的性质。但如果它们应该是，那么它们可能是错误的。

我希望这能为您清除一些事情。

Answer 2

将 url 的操作 url 注入 ajax 调用的最佳方式是什么？

就我个人而言，我在 AJAXify 的 DOM 元素上使用 HTML5 data-* 属性。例如：

<div id="foo" data-url="@Url.Action("foo")">Foo Bar</div>

然后：

$('#foo').click(function() {
    var url = $(this).data('url');
    // TODO: perform the AJAX call
});

当然，如果 DOM 元素表示锚点或表单，我将使用本机属性（action 或 href）。

选择JsonBehavior时有哪些考虑因素？

没有具体的考虑。请记住，GET 请求可能会被客户端浏览器缓存，因此您可能需要在客户端上指定 {cache: false }。哦，当然还有服务器上的 Json 的AllowGet。

在服务器端处理错误的最佳方法是什么？

我个人使用 FluentValidation.NET 来处理视图模型上的验证错误。也可能存在来自服务层。

在客户端处理错误的最佳方法是什么？

如果服务器返回 JSON，我通常有一个如下所示的结构：

{ error = 'some error message', result: null }

或：

{ error = null, result: { foo: 'bar' } }

取决于是否有错误，并且在客户端：

success: function(data) {
    if (data.error != null && data.error != '') {
        // error
    } else {
        // use data.result
    }
}

我对客户端上未处理的异常的所有内容使用 error 回调服务器在这种情况下只显示一些通用错误消息。可以使用 $.ajaxSetup 指定全局错误处理程序。

为了简化服务器上​​这些 JSON 结果的生成并干燥我的操作，我使用自定义操作过滤器来测试该请求是否是 AJAX 请求，如果是 AJAX 请求，则测试是否有验证错误添加到 ModelState 中以及它们是否存在我们将操作结果替换为自定义错误 JsonResult 以处理错误情况。

Answer 3

以下是我在最近的一些项目中所做的事情：

1）我使用 Url.Action 调用将 ajax url 注入视图中。

2) Jqgrid 使用 GET 来获取网格数据，因此在填充网格控制器操作中，我需要在 Json 方法调用中使用 JsonRequestBehavior.AllowGet 开关。

3）我最近切换到微软的不显眼的客户端验证，它有一个简洁的 ModelState.IsValid 方法，您可以在控制器操作中运行服务器端，以确保同样的验证也在服务器端运行，而无需重复代码。需要一些工作来将其与 jquery.maskedinput 等相结合以屏蔽/取消屏蔽数据，这里有一篇关于如何让所有这些发挥作用的文章。

4）关于显示错误客户端，这是一个设计问题，必须由利益相关者充实。就我个人而言，我不喜欢文本框旁边的验证或页面顶部的验证摘要。我更喜欢错误在你面前跳出来，所以我调整了 Microsoft 的 jquery.validate.unobtrusive.js 以在弹出模式对话框中显示错误。您可以在 jquery.validate.unobtrusive.MOD.js 文件中看到上述解决方案中的代码（注意我的版本带有“.mod.js”后缀），并且您可以在 Site.Master 中看到错误对话框。

控制器操作示例：

[HttpPost]
    public ActionResult Index(PersonalInformation model)
    {
        if (ModelState.IsValid)
        {
            // TODO: sell personal information to sleazeballs

            TempData["PersonalInformation"] = model;

            return RedirectToAction("Success");
        }

        // If we got this far, something failed, redisplay form
        Index_Load();
        return View(model);
    }

希望这有帮助，

罗伯特