Comments 37
UFO just landed and posted this here
А мне не особо понравилось. Не смог уж всю прочитать — слишком много воды. Я в вопросы ViewState особо не вникал раньше, но все как тут описано — так и представлял себе поведение ViewState (хотя, так как читал между строк, может быть что-то и пропустил, что раньше не знал или не представлял).
А автору бесспорно громадный плюс за отличный перевод. Читая, сразу понял, что перевод, у нас так не пишут. Но все же перевод качественный. Будем ждать еще таких интересных переводов.
А автору бесспорно громадный плюс за отличный перевод. Читая, сразу понял, что перевод, у нас так не пишут. Но все же перевод качественный. Будем ждать еще таких интересных переводов.
Рекомендую вам все же дочитать до конца. В свое время я тоже бросил оригинал, не дойдя и до середины, и несколько раз сильно об этом пожалел. Так и мучался, пока не заставил себя прочитать все же всю статью.
А за отзыв о переводе — отдельное спасибо!
А за отзыв о переводе — отдельное спасибо!
Ну не надо :) В общем все представляют, а когда конкретно всё начинаешь делать, получаешь кашу из событий-обработчиков и вьюстейт на 50кб (ведь не от хорошей жизни мне приходилось писать кастомный сериализатор и сжатие).
Вопрос к автору перевода: вам не кажется, что для начала было бы неплохо объяснить, о чем речь, или сразу поместить статью в блог, где таких вопросов не возникнет?
Да, вы правы. Простите, если статья сбила вас с толку.
Насчет блога — я выбирал между .NET или «Веб-разработка» (к сожалению, блога ASP.NET на хабре не оказалось), и в итоге выбрал последнее. Может быть, стоит все же перенести в .NET?
Насчет блога — я выбирал между .NET или «Веб-разработка» (к сожалению, блога ASP.NET на хабре не оказалось), и в итоге выбрал последнее. Может быть, стоит все же перенести в .NET?
я только в шестом абзаце встретил слово ASP и понял, что мне эта статья не интересна. ну как так можно, блин)
ох, непосредственно на ASP.NET'е я не разрабатывал, но находился «по другую сторону баррикад» — писал автосабмиттер для сайта на аспнете… С этими viewstate, eventvalidation и hiddenfield намучился изрядно…
З.Ы. автосабмиттер — не спамерский, как можно подумать, а легальный, что-то вроде десктоп клиента для нескольких сайтов.
З.Ы. автосабмиттер — не спамерский, как можно подумать, а легальный, что-то вроде десктоп клиента для нескольких сайтов.
Фак. Жесть. Десктоп клиент, который работает на передаче данных напрямую на сайт? Вот это мосье знает толк в извращениях!
Там не было к сожалению альтернатив.
Сайты в большинстве своем либо не имеют специального АПИ, либо не дают его.
Наш софт в некотором роде унифицирует сайты, позволяя контрибуторам делиться контентом даже с малопопулярными без лишнего гемора. Лидерам это ясно понятно не нравится, поэтому АПИ они не дают.
Сайты в большинстве своем либо не имеют специального АПИ, либо не дают его.
Наш софт в некотором роде унифицирует сайты, позволяя контрибуторам делиться контентом даже с малопопулярными без лишнего гемора. Лидерам это ясно понятно не нравится, поэтому АПИ они не дают.
А что собственно такого, если к движку сайта доступа нет, только в «админку», а её интерфейс заказчику не нравится?
Недавно с товарищем обсуждали вариант использования Session вместо ViewState. (При отключенном ViewState, при условии что хранится будут небольшие объемы данных, например различные id, расход памяти на сервере предполагается небольшой.)
Про объект Cahce для хранения не привязанных к конкретному посетителю данных тоже не забываем.
А что вы, и читатели думаете по этому поводу? Насколько оправдана такая замена?
Вообще многие ли используют ViewState? Среди многих разработчиков которых знаю есть тенденция полностью его отключать.
Про объект Cahce для хранения не привязанных к конкретному посетителю данных тоже не забываем.
А что вы, и читатели думаете по этому поводу? Насколько оправдана такая замена?
Вообще многие ли используют ViewState? Среди многих разработчиков которых знаю есть тенденция полностью его отключать.
ViewState вне пределов призван «скрывать» stateless природу веб-приложений для новичков, переползших с десткоп разработки. Такова была концепция веб-формс. Если вы умеете мыслить за пределами этой концепции, то ViewState не нужен.
Ну полностью он все равно не отключится. В смысле ControlState будет работать, а хранится он во ViewState. Т.е. дефолтные компоненты все равно в каком то роде используют ViewState. Хотя Cache это конечно здорово, вообще везде где можно нужно отказываться от всего, что можно бы бы заменить Cache.
Статья переехала в блог .NET (а все-таки блога ASP.NET не хватает!), добавилось небольшое вступление. Еще раз прошу прощения у всех, кого успел ввести в заблуждение первоначальным вариантом.
имхо, лучшее, что можно сделать с вьюстейтом — это <pages enableViewState=''false''...>
Спасибо за статью! Интересно почитать.
Первый вопрос на собеседованиях для ASP.NET-программиста
UFO just landed and posted this here
А в чем, собственно, проблема, и что здесь обсуждать? Просто ASP.NET контролы все настройки свои запихивают в ViewState в надежде, что их будут использовать как в WinForms (сначала задали одно свойство, после отправки формы другое). На деле это просто не нужно практически никогда, но для новичков полезно при изучении ASP.NET.
Ну а сложные элементы типа Grid — это просто примеры некачественного программирования. Они запихивают как состояние (например, состояние сортировок), так и настройки в viewState и отключить настройки, не отключая состояние нельзя.
Пишите свои качественные контролы, разумно работающие (а лучше вообще не работающие) с viewState.
Ну а сложные элементы типа Grid — это просто примеры некачественного программирования. Они запихивают как состояние (например, состояние сортировок), так и настройки в viewState и отключить настройки, не отключая состояние нельзя.
Пишите свои качественные контролы, разумно работающие (а лучше вообще не работающие) с viewState.
Отличная статья — занес в список для рекомендаций начинающим АСП.нетчикам.
Подскажите, если используешь ASP.NET MVC, то имеет ли смысл читать статью?
Вьюстейт с MVC использовать нельзя, концепция этих подходов к разработке разная.
MVC принимает http протокол как неизбежность, и не пытается оградить разработчиков от него, городя абстракции, жизненный цикл страницы, вьюстейты и апдейтпанели. Плюс используется MVC паттерн, что делает проекты дружелюбными к юнит тестам, например.
Web Forms же пытается косить под WinForms, но жизнь есть жизнь, и у такой дружелюбности к тем, кто переходит с вин формс, есть своя цена вроде таких штук. Ещё одна цена — невозможность сайта работать с отключённым джаваскриптом.
MVC принимает http протокол как неизбежность, и не пытается оградить разработчиков от него, городя абстракции, жизненный цикл страницы, вьюстейты и апдейтпанели. Плюс используется MVC паттерн, что делает проекты дружелюбными к юнит тестам, например.
Web Forms же пытается косить под WinForms, но жизнь есть жизнь, и у такой дружелюбности к тем, кто переходит с вин формс, есть своя цена вроде таких штук. Ещё одна цена — невозможность сайта работать с отключённым джаваскриптом.
ViewState — это костыль и прошлый век… я за MVC…
UFO just landed and posted this here
переводчик в прозе раб, в поэзии — соперник
статья супер. До ее прочтения я ненавидел ViewState, теперь я понимаю что просто неправильно его использовал.
UFO just landed and posted this here
Прошу простить за буквоедство, но мне кажется что «Неправильное использование ViewState'а» должно быть заголовком.
Нашел визуальное объяснение, как говорится «на пальцах». Пожалуйста, товарищи.
В качестве раздела библиография, который отсутсвует могу предложить.
«Фриц Оньон. Основы ASP. NET с примерами на С# 2003», глава 2 «Веб-формы», эта глава покрывает статью, о проценте покрытия не могу сказать (Он про ASP.NET 2.0)
«Фриц Оньон. Основы ASP. NET с примерами на С# 2003», глава 2 «Веб-формы», эта глава покрывает статью, о проценте покрытия не могу сказать (Он про ASP.NET 2.0)
Sign up to leave a comment.
Настоящее понимание ViewState'а