Что такое "жизненный цикл страницы" страницы ASP.NET MVC, по сравнению с ASP.NET WebForms?

Что такое "жизненный цикл страницы" страницы ASP.NET MVC, по сравнению с ASP.NET WebForms?

Я пытаюсь лучше понять этот "простой" вопрос, чтобы определить, могут ли существующие страницы, которые у меня есть на (очень) простом сайте, легко конвертироваться из ASP.NET WebForms.

Либо "преобразование" процесса ниже, либо альтернативный жизненный цикл будет тем, что я ищу.

То, что я сейчас делаю:

(да, я знаю, что любой, кто может ответить на мой вопрос, уже знает все это - я просто пытаюсь получить сравнение "жизненного цикла", поэтому я подумал, что начну с заполнения того, что мы уже все знаем)

Отображение страницы:

  • У меня есть главная страница, содержащая мой основной шаблон
  • У меня есть страницы содержимого, которые дают мне названные области с главной страницы, на которую я помещал контент.
  • В обработчике событий для каждой страницы контента я загружаю данные из базы данных (в основном для чтения).
  • Я привязываю эти данные к элементам управления ASP.NET, представляющим сетки, выпадающие меню или повторители. Эти данные все "живут" внутри генерируемого HTML. Некоторые из них попадают в ViewState (но я не буду вдаваться в это слишком много!)
  • Я устанавливаю свойства или привязываю данные к определенным элементам, таким как элементы управления Image или TextBox на странице.
  • Страница отправляется клиенту, который отображается как непереработанный HTML.
  • Я стараюсь избегать использования ViewState, кроме того, что требуется как минимум для страницы.

Клиентская сторона (не использующая ASP.NET AJAX):

  • Я могу использовать JQuery и некоторые неприятные трюки, чтобы находить элементы управления на странице и выполнять операции над ними.
  • Если пользователь выбирает из выпадающего списка - генерируется обратная передача, которая запускает событие С# в моем кодебе. Это событие может перейти в базу данных, но независимо от того, что делает полностью созданная HTML-страница, она будет отправлена ​​обратно клиенту.
  • Я могу использовать Page.Session для хранения пар значений ключа, которые мне нужно повторно использовать позже

Итак, с MVC, как изменяется этот "жизненный цикл"?

Ответы

Ответ 1

Я попытаюсь прокомментировать каждый из упомянутых вами пунктов:

Ваши основные страницы все еще существуют в MVC и используются для обеспечения согласованной компоновки сайта. там не много нового.

Страницы вашего контента станут представлениями в мире MVC. Они по-прежнему предоставляют те же области содержимого на ваших основных страницах.

Обработка событий в веб-формах не должна использоваться в MVC, вместо этого ваши классы Controller и их методы действий будут обрабатывать загрузку ваших данных в "модель", которая передается в представление.

Несмотря на то, что в MVC возможно привязка данных в стиле веб-формы, я считаю, что это не оптимальное решение. Лучше поместить свои данные в класс модели и строго напечатать ваше представление, чтобы у вас был прямой доступ к этой модели. Тогда просто вопрос использования синтаксиса <%= ViewData.Model.SomeProperty %> для доступа к вашим данным и отображения его в нужных местах. Что касается viewstate, моя рекомендация - забыть, что она даже существует.

Помните, что одним из преимуществ использования MVC является то, что вы контролируете HTML-код, отправляемый клиенту. Обнимите эту мощь и попытайтесь найти решения, которые позволят вам поддерживать этот контроль. Элементы управления Webform пытаются скрыть html от вас и, как таковой, затрудняют настройку html, когда вам нужно.

Я бы очень рекомендовал JQuery или одну из других подобных мощных библиотек javascript. Но научитесь использовать их для прямого доступа к HTML DOM и избегайте проблем с элементами управления веб-формами.

Вы можете использовать jquery, чтобы подключиться к выпадающему меню на стороне клиента и отправлять стандартные или аякс-запросы. Этот запрос может возвращать новые страницы, перенаправления, фрагменты html или даже данные JSON, которые могут быть использованы для обновления существующей страницы.

Сессия asp.net может использоваться по мере необходимости.