Каковы преимущества scriptmanager по сравнению с прямыми вызовами jquery ajax?

Question

Я немного озадачен преимуществами или недостатками использования scriptmanager с вызовами ajax или использования JQuery для прямого вызова веб-методов.

Может кто-нибудь дать мне несколько советов по этому вопросу? когда использовать какой? Есть ли что-то другое, когда дело касается JSON?

Answer 1

Я думаю, что Страница управления MSDN ScriptManager хорошо суммирует функции -

• Зарегистрируйте скрипт, совместимый с частичными обновлениями страницы.

• Для управления зависимостями между вашим сценарием и ядром библиотека, любой скрипт, который вы регистрируете загружается после Microsoft AJAX Библиотечный скрипт.

• Укажите, будут ли сценарии выпуска или отладки отправляться в браузер.

• Предоставление доступа к методам веб-службы из сценария путем регистрации в Интернете. услуги с помощью ScriptManager управление.

• Предоставление доступа к проверке подлинности, роли и профилю ASP.NET. прикладные услуги от клиента скрипт при регистрации этих сервисов с элементом управления ScriptManager.

• Включить отображение ECMAScript (JavaScript) Date для конкретной культуры, Числовые и строковые функции в браузер.

• Доступ к ресурсам локализации для встроенных файлов сценариев или для автономные файлы сценариев с помощью ResourceUICultures собственность Элемент управления ScriptReference.

• Регистрация серверных элементов управления, которые реализуют IExtenderControl или IScriptControl взаимодействует с ScriptManager контролировать, чтобы скрипт требуется клиентскими компонентами и поведение отображается.

По сути ScriptManager делает то, что говорит, управляет вашими сценариями без особой заботы с вашей стороны, написав «клей» JavaScript, чтобы сделать это самостоятельно.

Конечно, есть (некоторые могут сказать, что значительные) издержки на включение элемента управления ScriptManager, не в последнюю очередь количество дополнительных запросов, сделанных для ресурсов сценария, и размер сгенерированных прокси-классов для вызова веб-служб и методов страницы. Это может быть не так важно при разработке приложения для интрасети, где пропускная способность и скорость сети, вероятно, будут меньшей проблемой по сравнению с разработкой приложения для Интернета, но, тем не менее, об этом следует знать.

Если вам удобна библиотека JavaScript, которая способна заменить все функции ScriptManager, при этом будучи более легкой и быстрой для выполнения задач, то это звучит как хороший случай не использовать ScriptManager.

С точки зрения работы с JSON и jQuery, и ScriptManager прекрасно с этим справляются. IIRC, JSON является типом данных по умолчанию для методов страниц и веб-служб в .NET (хотя что-то напоминает мне, что это не всегда так).

Answer 2

WRT Ajax звонит? Очень мало. Очень очень мало. Есть несколько возможных преимуществ для ASP.NET AJAX по сравнению с jQuery:

1. Синтаксис. Инфраструктура позволяет вам сделать так, чтобы ваши вызовы веб-службы выглядели так, как будто вы действительно вызываете какой-то локальный метод и передаете его параметры:

   MyNamespace.MyWebservice.MyMethod('arg1value', 'arg2value', onResult);
   

   Обратите внимание, как версия фреймворка знает порядок параметров в методе веб-службы.

   jQuery .ajax требует, чтобы была настроена сантехника для вызова метода веб-службы ASP.NET AJAX. Это минимально и в блоге о довольно . хорошо

   $.ajax({
     type: "GET",
     url: "MyWebservice.asmx/MyMethod",
     data: '{"arg1":"arg1value","arg2":"arg2value"}',
     contentType: "application/json; charset=utf-8",
     dataType: "json",
     success: function(data) {
       onResult(data.d) // ASP.NET returns payload in `".d"` property
     }
   });
   

2. JSON сериализация для передачи аргументов в веб-сервис: ASP.NET Ajax Framework имеет Sys.Serialization.JavaScriptSerializer.serialize, который выполняет работу по сериализации параметров вашего веб-сервиса "позади" сцены ". При наличии только jQuery может потребоваться включить третью библиотеку, например, JSON.stringify ¹ на json.org. Это настолько незначительно, что может показаться спорным.

3. Жесткое кодирование типов запросов GET и POST. Поскольку среда генерирует клиентский прокси-сервер JavaScript из определения класса WebService для вас, вы обычно не знаете (или не заботитесь) о том, каков метод HTTP-запроса в клиенте. Вы просто устанавливаете его в атрибуте ScriptMethod в своем классе веб-службы и вызываете его с клиента. С jQuery вы должны знать это, чтобы передать его .ajax в качестве опции type.

Что касается преимуществ, не связанных с Ajax, @ Russ Cam подвела их уже для вас.

---

¹ _{Встроенный в FF 3.1 и IE8 уже}