На одном из собеседований спросили рассказать про ViewState, как работает, зачем оно и т.д. Так что берем msdn  и разбираемся в понятии ViewState.

ViewState служит для сохранения изменей, которые были произведены на форме после postback (даже из названия можно догадаться - просмотр сосотяния). Если вы используете runat="server" контролы, то вам нужно обезательно разобраться в этом термине, так как он может нанести вред в будещем (на собеседовании нужно было работать  с ASP.NET MVC). По умолчению ViewState помещается в hidden поле с названием __VIEWSTATE. Это скрытое поле может стать очень большим - несколько десятков килобайт. Медлительность процеса вызывает не только загрузка этого поля, но и когда пользователь делает postback, то содержимое __VIEWSTATE переделывается в html.

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 несложно, разобраться, как его отключить — тоже. Можно отключить на уровне элемента управления, а можно — на уровне страницы: И тут начинаются проблемы. Либо начинают теряться введенные пользователем значения полей, исчезают наши внутренние данные, которые мы хранили в словаре View State, чтобы не возиться с собственными скрытыми параметрами или cookies. Теперь надо «прочесывать» код формирования страницы, чтобы заменить обращения к View State на что-то другое, а также отлавливать моменты, когда сбрасываются необходимые для пользователя значения «контролов». В общем, процесс разработки от таких переделок не ускоряется и надежность кода не увеличивается. Отсюда делаем простой вывод — не надо игнорировать ViewState. Все, что нужно, чтобы View State был полезен, а не вреден, это в начале работы над страницей подумать о том, как на данной странице оптимально использовать эту возможность. Если страница не предназначена для получения данных от клиента, либо если элементы управления на ней генерируются динамически, следует отключить View State на уровне страницы. В других случаях вам, возможно, понадобится отключить View State на уровне отдельных элементов управления. Не храните в словаре View State объемные данные, и не используйте его как аналог «кучи» для временных переменных. Такие действия с большой вероятностью приведут к проблемам в будущем