Является ли ASP.NET AJAX для скриптовых элементов управления тоже устарел?

#.net #asp.net #asp.net-ajax #asp.net-4.0

#.net #asp.net #asp.net-ajax #asp.net-4.0

Вопрос:

Я разрабатывал некоторые скриптовые элементы управления на стороне сервера с их аналогом на стороне клиента.

Поскольку я нашел несколько статей и вопросов Stakoverflow, касающихся того, что Microsoft практически устарела ASP.NET Клиентская библиотека AJAX в пользу jQuery, я беспокоюсь о том, не устарела ли разработка скриптовых элементов управления.

Я нахожу полезным ООП API Microsoft AJAX и его интеграцию с серверными элементами управления.

Наконец, в настоящее время я использую ASP.NET 4.0.

Заранее благодарю вас.


ЗАКЛЮЧЕНИЕ:

* Мой проект использует ScriptControls и API обратного вызова. Внутри ScriptControls я всегда использовал jQuery вместо клиентской библиотеки AJAX. Другими словами, я полагаю, что у меня нет жесткой зависимости от того, что должно быть устаревшим в будущих версиях .NET.

Текущий сценарий — .NET 5.0 достаточно удален, а текущая версия 4.0 содержит эти ASP.NET функции и на данный момент существуют официальные подходы, предоставляемые ASP.NET.

Поскольку .NET 4.0 еще некоторое время будет на рынке в качестве последней версии, и я сомневаюсь, что Microsoft сможет полностью удалить ASP.NET Функции AJAX 4.0 в версии 5.0, я считаю, что как ScriptControls, так и Callbacks будут безопасны в течение следующих 5 лет, и для меня этого достаточно.

Поправьте меня, если я ошибаюсь, но ScriptControls API обратного вызова jQuery (для манипулирования DOM) должны быть безопасными и хорошим способом для средне- и долгосрочной перспективе.*

Комментарии:

1. если у вас нет никаких проблем с использованием jquery, попробуйте перейти на это, поскольку теперь у вас больше возможностей для jquery.

2. @kobe но jQuery не охватывает некоторые функции, такие как интеграция элементов управления на стороне сервера. Нужно ли мне внедрять собственную интеграцию клиент-сервер с использованием taylored? Я не собираюсь переходить к ASP.NET MVC, мне нужны веб-формы, потому что моему решению нужна компонентно-ориентированная архитектура.

3. Примечание: Я не смог просмотреть ответы до завтрашнего утра по ГРИНВИЧУ 1, извините. Я прочитаю все завтра. Заранее ценю вашу поддержку!

4. Я проводил дополнительные исследования таким образом, и я нашел эту библиотеку: ajaxoop.org Может быть, вы найдете это полезным для того, чтобы иметь функции ООП MS AJAX без MS AJAX.

Ответ №1:

Да, справедливости ради, jQuery — это путь вперед сейчас. Для существующих проектов изменение может быть довольно болезненным, и если все работает так, как есть, я не понимаю, почему это все равно нужно менять.

Но если вы начинаете что-то новое, и если это продлится какое-то время (как и все программное обеспечение), тогда вам лучше использовать jQuery, поскольку он будет продолжать развиваться с течением времени, и вы сможете продолжать пожинать эти плоды.

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

Комментарии:

1. Это не проблема jQuery или не jQuery. Я знаю jQuery и использую его для этого проекта, но jQuery не интегрируется с серверными элементами управления «из коробки», вы знаете: D

2. На самом деле я никогда не слышал об этом проекте, я посмотрю. Я полагаю, что ваш ответ подходит для меня, потому что он проясняет мое мнение об этой проблеме. Мне нужно только перенести элементы управления скриптами в jQuery, но функции ScriptManager, такие как обратные вызовы и so, могут оставаться «как есть», потому что я нахожу их полезными, и это прекрасно работает в моем сценарии. Я предпочту оставить этот ответ не отмеченным как правильный, потому что я хочу выслушать больше мнений, но я поддержал его. Если завтра это останется наиболее ясным ответом, я отмечу это, не сомневайтесь 🙂 Спасибо за вашу поддержку.

3. Я просмотрел DJ, это кажется интересным. Я буду с нетерпением ждать профессиональных проектов, поскольку он кажется достаточно стабильным для этого.

Ответ №2:

Что ж, Microsoft давно прекратила поддержку LINQ to SQL в пользу Entity Framework, но люди все еще используют LINQ to SQL.

Хотя это правда, что Microsoft больше не прилагает усилий к дальнейшей разработке библиотеки MS AJAX, мне следует принять решение о том, использовать ее или нет, если целевые разработчики знают это лучше, чем другую библиотеку JavaScript (при условии, что время на выполнение задач является важным фактором).

Если вы начинаете с равной точки зрения, я бы, вероятно, выбрал jQuery, потому что он поддерживается Microsoft и есть большое сообщество, которое может помочь с проблемами, он находится в постоянной активной разработке, и это поможет, если вы решите перенести части приложения на ASP.NET MVC, который очень хорошо сочетается с jQuery.

Комментарии:

1. Но, например, как насчет ScriptManager. Это тоже каким-то образом устареет?

2. Я не думаю , что это было бы устаревшим, поскольку это неотъемлемая часть MS AJAX, UpdatePanels, генерирующих прокси для вызова веб-сервисов и т.д. Я думаю, можно с уверенностью предположить, что у него не будет дальнейшего развития.

3. Полезно знать и важный момент. Это меня беспокоило, поскольку я использую некоторые чрезвычайно полезные функции ScriptManager. Я поддержал этот комментарий и ваш ответ. Почему бы вам не добавить эту информацию в ответ? Я нахожу это полезным для других.