asp.net c# MVC: Как я живу без ViewState?

Некоторые связанные вопросы:

• Поддержание состояния просмотра в Asp.net mvc?
• ASP.NET MVC не работает с ViewState и Postback?

В большинстве традиционных веб-языков концепция среды с отслеживанием состояния на самом деле довольно необычна. Веб-формы ASP.NET являются исключением из правил, и они создают это исключение, заново изобретая множество стандартов. Цель Webforms состоит в том, чтобы абстрагироваться от концепции HTML и веб-разработки в целом, чтобы грань между настольным приложением и веб-приложением стиралась с точки зрения разработки. Обычно это означает, что решение, предоставляемое ASP.NET Webforms, хотя и эффективно, представляет собой универсальную реализацию, которая приводит к очень подробному выводу, который работает достаточно хорошо, чтобы удовлетворить большинство. И наоборот, основное преимущество ASP.NET MVC заключается в том, что он возвращает разработчикам контроль над выводом HTML и позволяет им создавать веб-приложения с сильной архитектурой RESTful , которые лучше определены и более понятны в их реализации и представлении, несмотря на некоторый уровень удобства.

Возможно, одним из самых больших недостатков модели Webforms является ViewState, поскольку она загромождает вывод, значительно увеличивает размер страницы в определенных сценариях и часто является эквивалентом использования отбойного молотка для развешивания изображения. Вместо того, чтобы пытаться использовать ViewState в вашем приложении MVC (или что-то похожее на него), вы должны начать использовать шаблоны, которые явно контролируют поля в ваших формах и оптимизируют операции ввода и вывода только с наиболее актуальными данными. Помимо изменений в разметке, вы также научитесь создавать лучше спроектированные решения, которые могут быть представлены в вашем приложении и за его пределами.

Сравнение номер один, которое мне нравится делать, простое: Webforms создает веб-страницы, а MVC создает веб-приложения. Если ваша повседневная работа заключается в основном в создании частей веб-сайта или добавлении небольших фрагментов функциональности, вы часто обнаружите, что веб-формы намного проще и требуют меньше времени; с другой стороны, если вы хотите создать полное приложение, которое можно тестировать, масштабировать и гибко, MVC - это ваше призвание.

viewstate - это просто большое, уродливое скрытое поле формы.

Напишите свои собственные скрытые поля формы, и зашифруйте их, если нужно.

К счастью, больше нет простого способа сбрасывать много-много данных на страницу, так что вы должны быть осмотрительны в выборе того, что хотите сохранить.

Если форма отправляется обратно на себя и т. Д. (т.е. обратная передача)? как page / usercontrol поддерживает свое состояние? Какие уловки люди делают, чтобы поддерживать какое-то состояние и не прибегать к состоянию сеанса?

Опубликованные ViewData (или строго типизированный объект, привязанный к странице) можно снова отправить в представление. См. «Интеграция логики проверки и бизнес-правил с классами моделей» в на этой странице. Он показывает, как вы можете опубликовать форму, проверить ее и вернуть поля обратно в форму в случае возникновения ошибки.

Какие концепции в .NET MVC делают ViewState чем-то, что не требуется?

Передача репрезентативного состояния (REST).

MVC имеет некоторые преимущества по сравнению с WebForms, но также имеет некоторые недостатки, о которых я подробно рассказал в ответе . Я думаю, что фундаментальный вопрос, который вы должны задать себе, заключается в том, является ли ViewState проблемой для вас сейчас - и является ли это такой проблемой, что вы должны переписать свое приложение? Если нет, то изучение MVC - достойная цель (это действительно круто), но не та, ради которой я бы рискнул бизнесом.

С учетом сказанного, ViewState может быть отключен в удивительно большом количестве случаев. Он используется в основном для сохранения значения элементов управления посредством обратной передачи. Так, например, если у вас есть текстовое поле, значение которого вы должны проверить на стороне сервера, а также множество других полей, ViewState позволит вам обработать обратную передачу, перехватить ошибку (и показать метку), а затем вернуть пользователя в форму со всеми его записями без изменений.Однако, если форма только будет заполнена и отправлена ​​обратно, а затем вы будете перенаправлены на другую страницу, вы можете безопасно отключить ее.

Наконец, вы спрашиваете, что люди делают, чтобы избежать состояния сеанса. Есть ли причина избегать состояния сеанса? Конечно, вам не нужно много информации, но избегать ее совсем не обязательно, и, по сути, это будет стоить вам одного из самых мощных инструментов в вашем арсенале.

нельзя использовать спецификатор [t] вместо [p] ?

Прочитайте этот пост на сайте Kinn StackExchange , который объясняет, почему они используют стабильный и девелоперский. Также предлагаются другие способы структурирования репозиториев.

Мы сохраняем стабильное хранилище данных. Новые функции переходят в девел и в конечном итоге получить слияние вперед стабильный, в то время как исправления ошибок переходят в стабильный и снова объединиться в Девел.

Состоянием является модель, находящаяся в базе данных. Вы можете тщательно кэшировать базу данных, чтобы сократить время загрузки страницы.

Автоматически сгенерированное состояние представления не существует в MVC, но вы можете написать собственное, просто используя скрытые поля,

В MVC вы не увидите много зашифрованных символов вверху страницы, которые вам не нужны. большинство из них.

Учтите тот факт, что движение REST в веб-программировании основано на идее, что состояние плохое для программы. В Википедии есть достойное описание со ссылками: http://en.wikipedia.org/wiki/Representational_State_Transfer

Исходя из традиционного ASP.NET и предоставляемой им богатой модели событий, MVC может быть довольно неприятным. Он действительно требует управления некоторыми вещами, которые раньше были невидимы для вас, но я думаю, что ценность с точки зрения тестируемости (страницы REST можно запускать легко, не создавая сложного состояния просмотра, и по определению сервер не поддерживает состояние, чтобы я мог тестировать страницу / функцию изолированно) компенсирует кривую обучения.

Для обсуждения MVC в ASP.NET и REST: http://blog.wekeroad.com/2007/12/06/aspnet-mvc-using-restful-architecture/

На самом деле так и есть. Вы должны забыть о том, как персистентность была придумана с помощью viewstate.

Вы также должны преобразовать в своем сознании постбэк на страницу в "вызов контроллера". Так все будет проще понять впоследствии. Вместо вызова страницы, вы вызываете контроллер, который возвращает представление. Таким образом, либо вы создаете всю "страницу" снова и снова при каждом вызове, либо вы решаете иметь дело только с тем, на что действительно влияет действие. Если кнопка изменяет div, зачем перезагружать всю страницу. Просто сделайте вызов контроллера и верните то, что должно быть новыми данными в div.

Например, давайте представим сценарий master/detail:

<h2>Groups</h2>
    <div id="GroupList">
    </div>
    <div id="GroupDetail" title="Detail Group">
</div>

Список групп загружается один раз в div и есть ajax вызов возможен к контроллеру для каждого элемента списка группы :

<%= Ajax.ActionLink("Edit", "DetailLocalisationGroup", 
                     new { id = group.Id }, 
                     new AjaxOptions() { 
                         UpdateTargetId = "DetailLocalisationGroup", 
                         OnSuccess = "InitialisationDetailGroup" })%>

который вызывает это действие DetailLocalisationGroup, которое должно передать div GroupDetail с html.

[AcceptVerbs("POST")]
public ActionResult DetailLocalisationGroup(int id)
{
    LocalisationGroup group = servicelocalisation.GetLocalisationGroup(id);
    return View("DetailGroup", group);
}

Теперь в div есть форма, и при нажатии на кнопку submit этой формы мы просто отправляем информацию, которая нам действительно нужна, в контроллер, который затем сохраняет данные в базе данных.

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

Все ответы, в которых говорится, что ASP.NET MVC не использует состояние, в основном верны. Но ASP.NET MVC действительно использует некоторое состояние, хотя оно не работает так, как ViewState.

Обычно, когда кто-то отправляет данные в ваше приложение, вы хотите проверить их и вывести ошибку, если данные не соответствуют действительности. Однако если вы просто вернете страницу с сообщением об ошибке, то когда пользователь нажмет F5, чтобы перезагрузить страницу, данные будут отправлены повторно. Обычно это не то, чего вы хотите. Таким образом, когда вы понимаете, что данные, отправленные в POST, не соответствуют действительности, вы хотите сказать пользователям, чтобы они получили эту страницу (или, возможно, другую страницу) и показали сообщение об ошибке. Вы делаете это, возвращая код состояния HTTP Redirect. Однако, как только пользователь получит GET-запрос, как вы узнаете, какое сообщение об ошибке следует отобразить? Вам придется каким-то образом помнить об этом с того момента, как вы (сервер) обработаете POST до того, как вы обработаете GET.

Для этого вы используете функцию ASP.NET MVC под названием TempData. На самом деле это просто обертка вокруг Session, которая гарантирует, что все, что вы поместите в словарь TempData, останется там до следующего запроса и не дольше.