Microsoft 的 AJAX 工具包与 jQuery
我们的团队从 Atlas 时代起就一直使用 Microsoft 的 AJAX 工具包。由于有点天真，我们错过了 jQuery/Prototype 现象，直到一个月或两个回来。到目前为止，我们总是将Ajax 的概念与微软的工具包联系在一起。
在阅读 jQuery 的过程中，我看到了 Ajax 的全新一面，而我之前只是模糊地意识到这一点。也就是说，您可以使用 JavaScript（或 JS 库）与服务器对话，而无需使用专门的控件。乍一看，这似乎提供了更好的浏览器兼容性和更少的膨胀。我当然对此感兴趣。
我向社区提出的问题：
当使用 ASP.NET 并需要在没有回发的情况下与服务器进行通信时，如何决定使用 AJAX 工具包中的控件而不是使用 jQuery 之类的控件？有理由同时使用两者吗？
Our team has been using Microsoft's AJAX Toolkit since the days of Atlas. In a bit of naivety we missed the jQuery/Prototype phenomenon until a month or two back. Until now, we have always associated the concept of Ajax with Microsoft's toolkit.
In reading up on jQuery I'm seeing a whole new side of Ajax that I was only vaguely aware of. That is, you can use JavaScript (or a JS library) to talk to the server without using a specialized control. At first glance, it seems like this offers better browser compatibility and less bloat. I'm certainly interested in it.
My question to the community:
When working with ASP.NET and faced with the need to communicate with the server without a postback, how does one make the determination to use a control from the AJAX Toolkit instead of working with something like jQuery? Is there a reason to use both?
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（6）
我发现团队对 JavaScript 和 DOM 的熟练程度使得 jQuery 相对于 MS 控件的使用产生了巨大的差异。如果团队很高兴不知道 DOM、HTTP、异步操作、事件驱动的 UI，或者 JSON 的含义以及为什么它是猫的喵叫，那么我会坚持使用 AjaxControlToolkit。
另一方面，如果他们一直尝试使用工具包直接通过 JavaScript 操作控件，那么 jQuery 可以减轻操作 DOM 的痛苦。
最后，如果您的团队可以使用 .NET 控件更快地进入市场，请坚持使用它来完成应用程序的整体交付，并让他们慢慢地尝试 jQuery 来处理一些零碎的东西（动画、jquery ui、
. bind()并将行为与表示分离）。最终，您要么 a) 获得足够的经验，可以将新页面/应用程序转换为 100% jQuery，要么 b) 赚到足够的钱来聘请精通 DOM 脚本的人员并亲自教授团队；)I've found the proficiency of the team with JavaScript and the DOM makes a huge difference on the uptake of jQuery over MS controls. If the team is happily unaware of the DOM, HTTP, asynchronous operations, event driven UIs, or what JSON means and why it's the cat's meow, I'd stick with AjaxControlToolkit.
If on the other hand they are consistently trying to work around the toolkit to manipulate a control directly via JavaScript, jQuery takes the pain out of manipulating the DOM like this.
In the end, if your team can get to market faster with .NET controls, stick with it for the overall delivery of the app and have them slowly try jQuery for bits and pieces here and there (animations, jquery ui,
.bind()and separating behavior from presentation). Eventually you either a) get enough experience that you can transition new pages/apps to 100% jQuery or b) make enough money to hire someone proficient at DOM scripting and teach the team themselves ;)好问题。
我相信，虽然 AJAX Toolkit 控件仍然有一席之地（就像经典 Web 窗体一样），但使用 jQuery 时您的代码将更加干净且易于维护。但最重要的是，您将对代码的行为方式拥有更多的控制力和灵活性。
您始终可以在特定情况下使用某些控件，而在其余情况下使用 jQuery。我认为同时采用这两种方法并没有什么根本性的错误。
Good question.
I believe that while there's still place for the AJAX Toolkit controls--as there is for classic Web Forms--your code will be cleaner and easier to maintain when using jQuery. But above all you'll have much more control and flexibility over how your code behaves.
You can always use some controls for specific situations, using jQuery for the rest. I don't think there is anything fundamentally wrong with employing both approaches simultaneously.
虽然 Microsoft AJAX 工具包使用方便且简单，但当您想要执行比您设计的更复杂的操作时，很容易很快遇到障碍。如果您有兴趣通过友好的库了解 AJAX 的详细信息，JQuery 是您的最佳选择。这些知识将跨多个平台进行翻译；例如，如果您的团队决定尝试使用 Django、Ruby on Rails 等，那么您已经将 JQuery 作为首选 AJAX 工具包。如果您计划从 ASP.NET 迁移到 ASP.NET MVC（Microsoft 已将 JQuery 称为官方客户端 JavaScript 工具包），则尤其如此。
While the Microsoft AJAX Toolkit is convenient and simple to drop in, its easy to quickly hit barriers when you want to do anything more complicated than what you designed. If you're interested in learning the ins and outs of AJAX with a friendly library, JQuery is the way to go. This knowledge will translate across multiple platforms; for instance, if your team decides to try using Django, Ruby on Rails, etc. then you already have JQuery as your go-to AJAX toolkit. This is especially true if you're ever planning to move from ASP.NET to ASP.NET MVC for which Microsoft has dubbed JQuery the official client-side javascript toolkit.
我很久以前就停止使用 MS Ajax 了，因为我开发的许多应用程序都需要能够正常访问和降级。即不显眼的 Javascript。我坚信 MS 最终会朝这个方向发展他们的 Javascript 东西，但现在还不是时候。
基本上我开发的每个网页都没有内联 JavaScript，除了 js 文件的外部链接之外，该页面将在关闭 JavaScript 的情况下工作。这是我的首要任务，但可能不是你或其他任何人的优先任务。如今，我们不会梦想在 html 中而不是在外部 css 文件中放置字体标签。随着时间的推移，我们可能会对脚本有同样的想法。
I stopped using the MS Ajax stuff a long time ago because many of the applications I develop need to be accessible and degrade gracefully. i.e. Unobtrusive Javascript. I firmly believe that MS will eventually move their Javascript stuff in that direction but not just yet.
Basically every web page I develop will have no inline javascript whatsoever bar the external links to js files and the page will work with javascript off. This is my priority but may not be yours or anyone elses. These days we wouldn't dream of placing a font tag in html rather than our external css files. Over time we will probably think the same about script.
在我看来，这取决于你更喜欢哪个。
微软使用拖放删除诸如更新面板之类的控件，因为 jquery 是手工编写的，根据我的经验，它提供了更大程度的灵活性。
JQuery 似乎是目前 DOM 脚本和 AJAX 的首选框架，它只是使 javascript 相关任务更快、更容易实现。
imo it is down to which ever you prefer.
Microsoft uses drag & drop controls like update panel, where as jquery is written by hand and in my experience offers a greater degree of flexibility.
JQuery seems to be the framework of choice at the moment for DOM scripting and AJAX, it just makes javascript related tasks a lot quicker and easier to implement.
AJAX Toolkit 是一个重大“遗留问题”问题的产物。
MSFT 必须支持 ASP(X)、Web 表单等...
ASP（和 JSP）是 10 多年历史概念的实现：在服务器端创建 HTML 页面。整个“交互性”是通过表单提交实现的。并且不可避免地会重新加载页面。页面设计过去/现在只能通过 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
AJAX Toolkit is a product of a great "legacy problem" issue.
MSFT has to support ASP(X), web forms, etc...
ASP (and JSP) are implementations of 10+ years old concept: creating HTML page on the server side. The whole "interactivity" is/was achieved with FORM submit. And inevitable page re-loads. Page design was/is possible only with Visual Studio, and in reality is very difficult.
All together this is not AJAX. World has moved on.
jQuery means AJAX. jQuery is javascript library for AJAX clients. It uses DOM and few other HTML+browser features. AJAX/jQuery is server agnostic: any web server will do.
AJAX and jQuery, means total decoupling.
MSFT AjaxToolit is very closely coupled with ASP(X), and inevitably IIS. That was yesterday.
On the other side, jQuery is forcing you to adopt thinking of today. Which is a good thing,
especially if you are raised on ASP, and you want/need to move on.
Fortunately MSFT has realised it has to move on too, and ASP.NET MVC + jQuery was "allowed".
It is not 100% AJAX architecture, but a very good step into the right direction.
It is not webforms. It is not ascx.
Advice: never have one team develop web server side and web app client side. Use AJAX+REST+JSON. Have two decoupled teams developing loosely coupled web app.
--DBJ