微软的 AJAX 工具包与 jQuery答案

【问题标题】：Microsoft's AJAX Toolkit vs. jQuery微软的 AJAX 工具包与 jQuery
【发布时间】：2010-12-02 08:57:54
【问题描述】：

自 Atlas 时代以来，我们的团队就一直在使用 Microsoft 的 AJAX 工具包。在bit of naivety 中，我们错过了 jQuery/Prototype 现象，直到一两个月前。直到现在，我们一直将 Ajax 的概念与微软的工具包联系在一起。

在阅读 jQuery 时，我看到了 Ajax 的全新一面，而我只是模糊地意识到了这一点。也就是说，您可以使用 JavaScript（或 JS 库）与服务器对话，而无需使用专门的控件。乍一看，这似乎提供了更好的浏览器兼容性和更少的臃肿。我当然对此很感兴趣。

我向社区提出的问题：
当使用 ASP.NET 并需要在没有回发的情况下与服务器进行通信时，如何决定使用 AJAX 工具包中的控件而不是使用 jQuery 之类的控件？有理由同时使用两者吗？

【问题讨论】：

Scott Gu 说这是官方的 MS 善良，您还需要什么？ :) weblogs.asp.net/scottgu/archive/2008/09/28/…
@James - 绝对是靠 jQuery 的好处出售的（部分原因是 Visual Studio 的官方支持），现在正试图确定我们使用它的程度。我喜欢 crescentfresh 的答案，因为它是一个非主观的答案（说服其他人切换，因为“我喜欢它”具有挑战性）。
我想对你来说，使用任何你可以最高效的解决方案，而不会给最终用户带来性能问题。例如，我喜欢 UpdatePanels，但它们会产生大量的回发。当有很多交互时我仍然使用它们，但是对于通信本质上是单向的事情，比如弹出延迟加载的信息框，我喜欢使用 JQuery 和 PageMethods，如下所示：encosia.com/2008/05/29/… 并且 JQuery 很棒用于添加快速对话框、显示和隐藏内容以及快速重载事件。玩得开心！

标签： asp.net javascript jquery ajax ajaxcontroltoolkit

【解决方案1】：

我发现团队对 JavaScript 和 DOM 的熟练程度对 jQuery 对 MS 控件的采用产生了巨大影响。如果团队很高兴不知道 DOM、HTTP、异步操作、事件驱动的 UI 或 JSON 的含义以及为什么它是猫叫，我会坚持使用 AjaxControlToolkit。

另一方面，如果他们一直在尝试绕过工具包来直接通过 JavaScript 操作控件，那么 jQuery 可以避免像这样操作 DOM。

最后，如果您的团队可以使用 .NET 控件更快地进入市场，请坚持使用它来完成应用程序的整体交付，并让他们慢慢地尝试 jQuery 零零碎碎（动画、jquery ui、@ 987654321@ 并将行为与演示分开）。最终，您要么 a) 获得足够的经验，将新页面/应用程序转换为 100% jQuery，要么 b) 赚到足够的钱聘请精通 DOM 脚本的人并自学团队；)

【讨论】：

好点 - 虽然我认为缺乏知识可能会在专业上伤害他们。强迫团队提高他们对 JS/DOM 的了解可能是手动完成的另一个原因。

【解决方案2】：

好问题。

我相信，尽管 AJAX 工具包控件仍然存在——就像经典的 Web 表单一样——使用 jQuery 时，您的代码会更干净且更易于维护。但最重要的是，您将对代码的行为方式拥有更多的控制权和灵活性。

您总是可以针对特定情况使用一些控件，其余的使用 jQuery。我不认为同时使用这两种方法有什么根本上的错误。

【讨论】：

【解决方案3】：

虽然 Microsoft AJAX 工具包方便且易于使用，但当您想做比您设计的更复杂的事情时，它很容易快速突破障碍。如果您有兴趣通过友好的库了解 AJAX 的来龙去脉，那么 JQuery 是您的最佳选择。这些知识将在多个平台上进行翻译；例如，如果您的团队决定尝试使用 Django、Ruby on Rails 等，那么您已经将 JQuery 作为您的首选 AJAX 工具包。如果您曾经计划从 ASP.NET 迁移到 ASP.NET MVC（Microsoft 将 JQuery 称为官方客户端 javascript 工具包），则尤其如此。

【讨论】：

【解决方案4】：

我很久以前就停止使用 MS Ajax 了，因为我开发的许多应用程序都需要可访问和优雅地降级。即不显眼的Javascript。我坚信 MS 最终会将他们的 Javascript 东西朝那个方向发展，但还不是现在。

基本上，我开发的每个网页都没有内联 javascript，除了 js 文件的外部链接之外，该页面将在关闭 javascript 的情况下工作。这是我的首要任务，但可能不属于你或其他任何人。这些天来，我们不会梦想在 html 中而不是在我们的外部 css 文件中放置一个字体标签。随着时间的推移，我们可能会对脚本有同样的想法。

【讨论】：

【解决方案5】：

这取决于你喜欢哪个。

Microsoft 使用更新面板等拖放控件，其中 jquery 是手工编写的，根据我的经验提供了更大程度的灵活性。

JQuery 似乎是目前 DOM 脚本和 AJAX 的首选框架，它只是让 javascript 相关的任务更快更容易实现。

【讨论】：

感谢您的反馈。我希望它不会是主观的，但也许就是这样。

【解决方案6】：

AJAX Toolkit 是一个巨大的“遗留问题”问题的产物。 MSFT 必须支持 ASP(X)、Web 表单等... ASP（和 JSP）是 10 多年前概念的实现：在服务器端创建 HTML 页面。整个“交互性”是/通过 FORM 提交实现的。并且不可避免的页面重新加载。页面设计曾经/现在只能使用 Visual Studio，实际上非常困难。总之，这不是 AJAX。世界已经前进。 jQuery 表示 AJAX。 jQuery 是用于 AJAX 客户端的 javascript 库。它使用 DOM 和一些其他 HTML+浏览器功能。 AJAX/jQuery 与服务器无关：任何 Web 服务器都可以。 AJAX 和 jQuery，意味着完全解耦。 MSFT AjaxToolit 与 ASP(X) 紧密结合，并且不可避免地与 IIS 结合。那是昨天。另一方面，jQuery 正迫使你采用今天的思维方式。这是一件好事，特别是如果您在 ASP 上长大，并且想要/需要继续前进。

幸运的是，MSFT 已经意识到它也必须继续前进，并且 ASP.NET MVC + jQuery 是“允许的”。它不是 100% AJAX 架构，而是朝着正确方向迈出的非常好的一步。它不是网络表单。它不是 ascx。

建议：永远不要让一个团队开发 Web 服务器端和 Web 应用程序客户端。使用 AJAX+REST+JSON。让两个解耦的团队开发松散耦合的 Web 应用程序。

--DBJ

【讨论】：