Комментарии 28
Так все-таки, использование UpdatePanel — это хорошо или плохо? ;)
Как-то в конце не хватает сравнения плюсов и минусов использования UpdatePanel'ей и веб-сервисов.
А по поводу xmlHttpRequest — кто ж с ним напрямую работает? Это неудобно, практически всегда лучше использовать какую-то обертку.
Как-то в конце не хватает сравнения плюсов и минусов использования UpdatePanel'ей и веб-сервисов.
А по поводу xmlHttpRequest — кто ж с ним напрямую работает? Это неудобно, практически всегда лучше использовать какую-то обертку.
Подправил и это. Теперь, вроде понятно…
А почему вы предлагаете использовать IsInAsyncPostBack какого-то ScriptManager'а? Ведь в одних асинхронных постбеках этот флаг будет true, а в других, возможно, false.
Я к тому, что каждой фиче — свое применение. Чтобы узнать, находится ли вся страница в состоянии асинхронного постбека, нужно использовать Page.IsInAsyncPostBack. Для того, чтобы проверить то же касательно конкретных элементов страницы, нужно использовать их флаг IsInAsyncPostBack.
К тому же, вы пишете:
Получается, что при использовании UpdatePanel страница проходит весь свой цикл, в независимости от того, как идет запрос: синхронно или асинхронно.
И затем пишете, что это можно исправить, использую проверку на асинхронность. Но на самом деле, страница ведь все равно будет проходить весь жизненный цикл. Другое дело, что при помощи таких проверок процесс протекания жизненного цикла можно контролировать.
Я к тому, что каждой фиче — свое применение. Чтобы узнать, находится ли вся страница в состоянии асинхронного постбека, нужно использовать Page.IsInAsyncPostBack. Для того, чтобы проверить то же касательно конкретных элементов страницы, нужно использовать их флаг IsInAsyncPostBack.
К тому же, вы пишете:
Получается, что при использовании UpdatePanel страница проходит весь свой цикл, в независимости от того, как идет запрос: синхронно или асинхронно.
И затем пишете, что это можно исправить, использую проверку на асинхронность. Но на самом деле, страница ведь все равно будет проходить весь жизненный цикл. Другое дело, что при помощи таких проверок процесс протекания жизненного цикла можно контролировать.
хм… странно, потому что ни я, ни яндекс, ни гугл, ни msdn, ни IntelliSense не знают о свойстве IsInAsyncPostBack у объекта Page… Обычно используют такую штуку: ScriptManager.GetCurrent(this.Page).IsInAsyncPostBack
А что касается прохождения через жизненный цикл, использование проверки на асинхронность снижает нагрузку на сервер, а соответсвенно практически убирает этот недостаток UpdatePanel'а.
А что касается прохождения через жизненный цикл, использование проверки на асинхронность снижает нагрузку на сервер, а соответсвенно практически убирает этот недостаток UpdatePanel'а.
Да и смысл словосочетания «какого-то ScriptManager» немного непонятен) ведь ScriptManager может быть только один на странице. А все прокси на него ссылаются…
По поводу Page.IsInAsyncPostBack дико извиняюсь! Это у нас в проекте есть BasePage, который наследуется от Page и реализует IsInAsyncPostBack через ScriptManager :) Привык уже к этому.
Вообще говоря, начало статьи было интересное — попытка отследить изменения ViewState'а и выяснить, что же передается внутри асинхронных запросов к серверу. А вот выводов из этого никаких нет, при этом пишете: «да и как оно работает так и не разобрались». надо ж было разобраться, а потом уже статью писать ;) Тем более, в интернете есть много статей, в которых процессы и механизмы детально описаны.
Сразу после этого сделали резкий переход на веб-сервисы, хотя статья у вас вроде как про использование UpdatePanel.
Я бы сказал, что UpdatePanel действительно облегчают разработку, и, конечно же, при обмене данными с сервером получается меньший траффик, чем при полной перезагрузке страницы. Однако объем передаваемых данных все равно зачастую больше минимального необходимого. В большинстве случаев это абсолютно не критично, но иногда, при активном обмене данными с сервером, лучше использовать веб-сервисы именно как замену асинхронным постбекам.
Вообще, у веб-сервисов круг применений намного шире и причин выбрать их может быть много. Например, универсальность программного интерфейса по обмену данных с сервером в целях создания нескольких пользовательских интерфейсов (e.g., мобильного, десктопного и вебового). И даже в таком случае вполне нормально, когда веб-сервисы используются только как прослойка между бизнес-логикой и интерфейсом, а интерфейс все равно оперирует стандартными средствами ASP.NET, в т.ч. UpdatePanel'ями, используя веб-сервисы только для обмена данными.
В то же время, у UpdatePanel есть множество преимуществ, ведь они, в отличие от веб-сервисов, разрабатывались специально для асинхронного изменения HTML-кода страницы. Отсюда удобные триггеры, вложенность панелей, автоматический рендеринг (который в противном случае вам прийдется реализовывать вручную на JS), и многое другое.
Сразу после этого сделали резкий переход на веб-сервисы, хотя статья у вас вроде как про использование UpdatePanel.
Я бы сказал, что UpdatePanel действительно облегчают разработку, и, конечно же, при обмене данными с сервером получается меньший траффик, чем при полной перезагрузке страницы. Однако объем передаваемых данных все равно зачастую больше минимального необходимого. В большинстве случаев это абсолютно не критично, но иногда, при активном обмене данными с сервером, лучше использовать веб-сервисы именно как замену асинхронным постбекам.
Вообще, у веб-сервисов круг применений намного шире и причин выбрать их может быть много. Например, универсальность программного интерфейса по обмену данных с сервером в целях создания нескольких пользовательских интерфейсов (e.g., мобильного, десктопного и вебового). И даже в таком случае вполне нормально, когда веб-сервисы используются только как прослойка между бизнес-логикой и интерфейсом, а интерфейс все равно оперирует стандартными средствами ASP.NET, в т.ч. UpdatePanel'ями, используя веб-сервисы только для обмена данными.
В то же время, у UpdatePanel есть множество преимуществ, ведь они, в отличие от веб-сервисов, разрабатывались специально для асинхронного изменения HTML-кода страницы. Отсюда удобные триггеры, вложенность панелей, автоматический рендеринг (который в противном случае вам прийдется реализовывать вручную на JS), и многое другое.
Честно говоря, я вообще недогоняю технологию ASP.Net.
Перед тем как попробовать APS.Net да и вообще .Net и веб-технологии майкрософта я долго сидел на PHP. Я уже знал что такое MVC и среду, поэтому когда увидел принципы работы ASP.Net я очень разочаровался.
Попытка синхронизации состояния сервера и клиента в среде, которая не хранит состояние, а также сильная связанность представления с бизнес-моделью, привели меня в недоумение. Да, можно быстро накидать нехилый функционал, но дьявол то в деталях. В следствие этого и начинаются всякие извивания как в виде тех же обращений к сервисам. Я вам прямо и скажу, что очень много программеров пишут сервисы (как вы и делаете в данной заметке) из-за недостатков технологии ASP.Net. Всё это очень печально.
Вот Microsoft MVC — это другое дело, а ASP.Net — прошлый век…
Перед тем как попробовать APS.Net да и вообще .Net и веб-технологии майкрософта я долго сидел на PHP. Я уже знал что такое MVC и среду, поэтому когда увидел принципы работы ASP.Net я очень разочаровался.
Попытка синхронизации состояния сервера и клиента в среде, которая не хранит состояние, а также сильная связанность представления с бизнес-моделью, привели меня в недоумение. Да, можно быстро накидать нехилый функционал, но дьявол то в деталях. В следствие этого и начинаются всякие извивания как в виде тех же обращений к сервисам. Я вам прямо и скажу, что очень много программеров пишут сервисы (как вы и делаете в данной заметке) из-за недостатков технологии ASP.Net. Всё это очень печально.
Вот Microsoft MVC — это другое дело, а ASP.Net — прошлый век…
А в чем именно проблема синхронизации состояния сервера и клиента?
По поводу сильной связи представления с бизнес-моделью вообще непонятно, что вы имеете в виду. Принятие всех решений о том, каким образом бизнес-логика взаимодействует с представлением, — абсолютная привилегия разработчика приложения. Здесь вообще сложно что-то навязать.
По поводу сильной связи представления с бизнес-моделью вообще непонятно, что вы имеете в виду. Принятие всех решений о том, каким образом бизнес-логика взаимодействует с представлением, — абсолютная привилегия разработчика приложения. Здесь вообще сложно что-то навязать.
Нет никаких проблем, всё решается. Я имею в виду, что если как бы «бегло» взглянуть, то может показаться, что ASP.Net спроектирован для быстрого перехода разработчиков от WinForms к Web. Понимаете?
Насчет связи представления — возьмите произвольный проект на ASP.Net и произвольный на MVC. В каком проекте будет больше геморроя изменить вёрстку?
Насчет связи представления — возьмите произвольный проект на ASP.Net и произвольный на MVC. В каком проекте будет больше геморроя изменить вёрстку?
Так не может показаться, а так и есть :) WebForms спроектированы по образу и подобию WinForms, по крайней мере, с точки зрения программистов, которые используют эти технологии.
Не совсем понятно, какое отношение имеет сложность изменения верстки к «связанности» бизнес-логики и представления, о чем вы упомянули в вашем первом комментарии и о чем я спросил.
Впрочем, MVC Framework мне и самому нравится больше, чем ASP.NET, хотя в текущем проекте пишу на чистом ASP.NET и не жалуюсь :) Все меняется достаточно просто, главное было — изначально построить архитектуру приложения так, чтобы она была удобной и поддерживаемой.
Не совсем понятно, какое отношение имеет сложность изменения верстки к «связанности» бизнес-логики и представления, о чем вы упомянули в вашем первом комментарии и о чем я спросил.
Впрочем, MVC Framework мне и самому нравится больше, чем ASP.NET, хотя в текущем проекте пишу на чистом ASP.NET и не жалуюсь :) Все меняется достаточно просто, главное было — изначально построить архитектуру приложения так, чтобы она была удобной и поддерживаемой.
Вам наверно очень везёт, что не попадаются проекты, где в aspx-ах зашиты валидаторы сущьностей, запросы и т.п. вещи, и где надо поменять методику ввода данных на каких то частях страницы или страниц и соответственно верстку или типа того… Кто то допустим накидал какой-то там грид, автоматом всё биндится и т.п. Круто! А вот надо потом кое что изменить, приходиться всё удалять, и писать бинд нормально на стороне сервера.
Естественно можно всё сделать грамотно, но, например возможность вставить валидатор объекта домена в файле html разметки, который отработает на сервере — это не по мне…
Естественно можно всё сделать грамотно, но, например возможность вставить валидатор объекта домена в файле html разметки, который отработает на сервере — это не по мне…
Между прочим, использовать чистый ASP.NET и реализовывать AJAX через веб-сервисы — чистой воды изврат. В этот случае мало что используется из самого ASP.NET, зачем тогда его вообще использовать? Это можно сравнить с использованием
Действительно уж, тогда лучше использовать MVC Framework.
<asp:literal>, выводя через него чистый HTML. (да, я видел и такое :))Действительно уж, тогда лучше использовать MVC Framework.
Ну, MVC и WebForms призваны решать разный круг задач, как мне кажется.
MVC направлен в большей части на работу клиентской части и верстку — это намного удобнее там, как минимум потому что код на странице не кажется таким громоздким и ID-шники элементов не меняются при рендере.
А ASP.Net имеет в своем корне событийную модель обработки. Это удобно, когда нам нужно получить сильный серверный функционал, практически не обращая внимание на клиентскую реализацию.
Тут уже нужно выбирать технологию от целей поставленных перед проектом =).
Согласен с авторами комментов — мне так же нравится MVC больше, чем ASP.Net. Сейчас (как и Shedal) пишу проект на WebForms — потому что задачи проекта требуют это. Но мне ничто не мешает прикрутить туда jQuery — имеются костыли при обращении к элементам по их ID, но все решаемо — больше трудозатрат только;)
MVC направлен в большей части на работу клиентской части и верстку — это намного удобнее там, как минимум потому что код на странице не кажется таким громоздким и ID-шники элементов не меняются при рендере.
А ASP.Net имеет в своем корне событийную модель обработки. Это удобно, когда нам нужно получить сильный серверный функционал, практически не обращая внимание на клиентскую реализацию.
Тут уже нужно выбирать технологию от целей поставленных перед проектом =).
Согласен с авторами комментов — мне так же нравится MVC больше, чем ASP.Net. Сейчас (как и Shedal) пишу проект на WebForms — потому что задачи проекта требуют это. Но мне ничто не мешает прикрутить туда jQuery — имеются костыли при обращении к элементам по их ID, но все решаемо — больше трудозатрат только;)
Это вы про ClientIDMode?
Да, это выход из ситуации, правда я на практике еще не применял
Да, это выход из ситуации, правда я на практике еще не применял
Знаете, было бы интересно провести сравнение работы подобных компонентов на ASP.Net и на JSP (Java, не знаю как точно указать). Где реализация удобнее, где затрат при формировании страниц меньше… Технологии похожи, между собой. Но все же Java имеет сравнительно бОльшее количество Framework'ов (vaadin, JavaServer Faces, ZK), которые предлагаю реализовать асинхронный режим работы на странице.
Кто-нибудь видел подобное сравнение? Или может написать об этом? :) Я думаю, что тема актуальная и интересная
Кто-нибудь видел подобное сравнение? Или может написать об этом? :) Я думаю, что тема актуальная и интересная
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
Использование UpdatePanel и иже с ним