Microsoft AJAX Toolkit против jQuery

Наша команда использует Microsoft AJAX Toolkit со времен Atlas. В наивности мы пропустили явление jQuery/Prototype до месяца или двух назад. До сих пор мы всегда связывали концепцию Ajax с набором инструментов Microsoft.

При чтении на jQuery я вижу совершенно новую сторону Ajax, о которой я только смутно знал. То есть вы можете использовать JavaScript (или JS-библиотеку) для общения с сервером без использования специализированного элемента управления. На первый взгляд, похоже, что это обеспечивает лучшую совместимость с браузером и меньшую раздутость. Меня это очень интересует.

Мой вопрос для сообщества:
Когда вы работаете с ASP.NET и сталкиваетесь с необходимостью связываться с сервером без обратной передачи, как сделать определение использовать элемент управления из AJAX Toolkit вместо работы с чем-то вроде jQuery? Есть ли причина использовать оба?

Ответ 1

Я нашел мастерство команды с JavaScript, и DOM имеет огромное значение для восприятия элементов управления jQuery над MS. Если команда счастливо не знает о DOM, HTTP, асинхронных операциях, пользовательских интерфейсах, управляемых событиями, или о том, что означает JSON и почему это кошачье мяу, я бы придерживался AjaxControlToolkit.

Если, с другой стороны, они последовательно пытаются обойти инструментарий для управления элементом управления непосредственно через JavaScript, jQuery берет на себя боль от манипулирования DOM, как это.

В конце концов, если ваша команда сможет быстрее выйти на рынок с помощью элементов управления .NET, придерживайтесь ее для полной доставки приложения и медленно пытайтесь использовать jQuery для бит и частей (анимации, jquery ui, .bind() и отделяя поведение от представления). В конце концов вы либо a) получите достаточный опыт, чтобы перейти на новые страницы/приложения на 100% jQuery или b) заработать достаточно денег, чтобы нанять кого-то, кто владеет сценариями DOM, и научить команду себе;)

Ответ 2

Хороший вопрос.

Я считаю, что, хотя для элементов управления AJAX Toolkit все еще есть место - как и для классических веб-форм, ваш код будет чище и проще поддерживать при использовании jQuery. Но прежде всего у вас будет гораздо больше контроля и гибкости в отношении того, как ведет себя ваш код.

Вы всегда можете использовать некоторые элементы управления для определенных ситуаций, используя jQuery для остальных. Я не думаю, что есть что-то принципиально неправильное с одновременным использованием обоих подходов.

Ответ 3

В то время как инструментарий Microsoft AJAX Toolkit удобен и прост в использовании, его легко быстро ударить по барьерам, когда вы хотите сделать что-то более сложное, чем то, что вы разработали. Если вы заинтересованы в изучении входов и выходов 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. Со временем мы, вероятно, подумаем о script.

Ответ 5

imo это до тех пор, когда вы предпочитаете.

Microsoft использует элементы управления перетаскиванием, такие как панель обновления, где, когда jquery написан вручную, и по моему опыту предлагает большую степень гибкости.

JQuery, по-видимому, является основой выбора для сценариев DOM и AJAX, он просто упрощает и упрощает выполнение javascript-задач.

Ответ 6

AJAX Toolkit является продуктом большой проблемы с "устаревшей проблемой". MSFT должен поддерживать ASP (X), веб-формы и т.д. ASP (и JSP) - это реализация концепции более 10 лет: создание HTML-страницы на стороне сервера. Вся "интерактивность" была достигнута с помощью FORM submit. И неизбежная перезагрузка страницы. Дизайн страницы был/возможен только с Visual Studio, и на самом деле это очень сложно. Все вместе это не AJAX. Мир двинулся дальше. jQuery означает AJAX. jQuery - это javascript-библиотека для клиентов AJAX. Он использует DOM и несколько других функций браузера HTML+. AJAX/jQuery является агностиком сервера: любой веб-сервер будет делать. AJAX и jQuery, означает полную развязку. MSFT AjaxToolit очень тесно связан с ASP (X) и неизбежно IIS. Это было вчера. С другой стороны, jQuery заставляет вас задуматься о сегодняшнем дне. Что хорошо, особенно если вы подняты на ASP, и вам нужно/нужно двигаться дальше.

К счастью, MSFT осознала, что ей тоже нужно двигаться, и ASP.NET MVC + jQuery был "разрешен". Это не 100% архитектура AJAX, но очень хороший шаг в правильном направлении. Это не веб-формы. Это не ascx.

Совет: никогда не создавайте одну команду на стороне веб-сервера и клиента веб-приложения. Используйте AJAX + REST + JSON. У вас две развязанные команды, разрабатывающие слабосвязанные веб-приложения.

- DBJ