Home

Публикация компании SEADMEX

Не возникало ли у вас ощущение, что во многие из проектов по разработке ПО, в которых вы участвовали как разработчик, чем-то похожи? А именно, в разных проектах, разные программисты допускают одинаковые, типовые ошибки. Конечно, речь не идет о синтаксических ошибках. Речь идет о «проблемном» коде, который поначалу удалось заставить работать, но впоследствии (во время разработки или, что гораздо хуже, после ввода в эксплуатацию) он становится источником различных неудобств и проблем.

То для смены пароля надо перекомпилировать программу, то «сделать такой отчет за то время, которое у нас осталось, абсолютно нереально», то web-приложение начинает тормозить уже при двадцати пользователях, хотя по плану их должно быть не меньше сотни. Особенно обидно, когда выясняется, что допущены элементарные ошибки, которых запросто можно было избежать. Но как заранее угадать, кто из программистов и какую «элементарную» ошибку совершит? К каждому программисту «контролера» не приставишь. Конечно, хотелось бы, чтобы все элементарные ошибки остались в курсовых проектах, выполненных во время обучения программированию. Но так не получается.

Есть известная практика тестировщиков — вести список типовых ошибок и способов их диагностики. Это существенно упрощает поиск багов в готовом приложении. Борьба с ошибками путем тестирования и последующей переделки продукта — обязательный этап разработки.

Однако можно сэкономить массу сил и времени, если научиться предотвращать ошибки. Для этого следует перенять у тестировщиков полезную практику ведения списка типовых ошибок. Для каждой ошибки такой список должен включать секцию «как избежать?». Держим список под рукой, кто предупрежден — тот вооружен. Но есть одна проблема. Ознакомление со списком не облегчает программисту жизнь (в отличие от тестировщика, который с помощью такого списка здорово экономит время). Почему? Да потому, что во многих случаях, чтобы не допустить ошибку, надо как минимум подумать. И нередко, чтобы застраховаться от проблем в будущем, нужно писать нетривиальный код, который опять же надо придумать. Скорее всего, программисты просто не будут читать все подряд на всякий случай. Но все же попробуем сделать первые шаги: представить описания ошибок в удобочитаемом виде — в виде небольших заметок, представлять эти заметки одну за другой, по мере накопления заметок — вводить классификацию типовых ошибок. Для начала — заметка об одной полезной возможности ASP.NET, способной, однако, «попортить кровь» программистам.

Применение View State в приложениях ASP.NET

View State — так в ASP.NET называется способ хранения данных о состоянии страницы в скрытом поле формы на самой странице. Когда форма передается от клиента на сервер, данные из скрытого поля используются, чтобы для конкретного клиента установить состояние серверных объектов, формирующих страницу. View State позволяет сохранять состояние клиентского web-интерфейса, при этом не используются ни cookies (которые могут быть отключены на клиенте), ни память сервера (которой может не хватить при работе большого количества пользователей).

View State используется во многих серверных элементах управления ASP.NET (например, DataGrid), чтобы запоминать их текущее состояние. Пример — сохранение значений полей формы на странице во время постраничного пролистывания списков.

Однако в применении View State есть не только плюсы, но и минусы.

Прежде всего, при использовании View State страница становится «тяжелее», как для обработки, так и для передачи клиенту, из-за дополнительного объема. Далее, дополнительная нагрузка связана с формированием и разбором данных скрытого поля View State. И, наконец, для обработки View State все-таки требуется память на сервере.

Некоторые серверные элементы управления, в частности, DataGrid, способны чрезвычайно активно использовать View State, даже тогда, когда в этом нет необходимости.

По умолчанию параметр View State включен. В этом-то и проблема. Вероятно, разработчики ASP.NET хотели таким образом привлечь внимание программистов к этой технологической «фиче». Отчасти им это удалось. Но те программисты, которые «не заметили» нововведения либо используют его бездумно, способны на ровном месте породить настоящих монстров. Обычный сценарий таков: программист использует ViewState неявно, работая с серверными «контролами», и иногда явно, потому что этот объект — удобный словарь для хранения собственных данных. «Объединенные усилия» серверных «контролов» и программиста легко приводят к неоправданному разбуханию, скрытого поля, содержащего данные ViewState, так что его объем может превысить объем страницы в несколько раз. Время отклика для пользователя увеличивается, приложение становится «неповоротливым». Работать с таким приложением через Интернет по слабому каналу может стать просто невозможно.

Далее возникает естественное желание уменьшить размер страницы. Обнаружить поле View State несложно, разобраться, как его отключить — тоже. Можно отключить на уровне элемента управления, а можно — на уровне страницы:

<%@ Page EnableViewState="false" %>

И тут начинаются проблемы. Либо начинают теряться введенные пользователем значения полей, исчезают наши внутренние данные, которые мы хранили в словаре View State, чтобы не возиться с собственными скрытыми параметрами или cookies. Теперь надо «прочесывать» код формирования страницы, чтобы заменить обращения к View State на что-то другое, а также отлавливать моменты, когда сбрасываются необходимые для пользователя значения «контролов». В общем, процесс разработки от таких переделок не ускоряется и надежность кода не увеличивается.

Отсюда делаем простой вывод — не надо игнорировать ViewState. Все, что нужно, чтобы View State был полезен, а не вреден, это в начале работы над страницей подумать о том, как на данной странице оптимально использовать эту возможность.

Если страница не предназначена для получения данных от клиента, либо если элементы управления на ней генерируются динамически, следует отключить View State на уровне страницы. В других случаях вам, возможно, понадобится отключить View State на уровне отдельных элементов управления. Не храните в словаре View State объемные данные, и не используйте его как аналог «кучи» для временных переменных. Такие действия с большой вероятностью приведут к проблемам в будущем.

Ссылки по теме:

Об управлении состоянием в web-формах: http://www.cybersecurity.ru/manuals/development/microsoft/489.html

Подробно о View State: http://www.uneta.org/default.aspx?mnuid=B76FB6BE-2CBA-45D8-85D8-6FD850A1FA5D&artID=0309B614-9525-4716-BAC2-1A8B00F8A21B

Не забудем и о MSDN — «Разработка эффективных web-приложений» (англ.): http://msdn2.microsoft.com/en-us/library/5dws599a.aspx