Что такое «жизненный цикл страницы» страницы 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 и некоторые неприятные приемы, чтобы найти элементы управления на странице и выполнить над ними операции.
• Если пользователь выбирает из выпадающего списка - генерируется постбэк, который вызывает событие C # в моем коде. Это событие может попасть в базу данных, но, что бы он ни делал, полностью сгенерированная HTML-страница в конечном итоге отправляется обратно клиенту.
• Я могу использовать Page.Session для хранения пар ключ-значение, которые мне понадобится позже

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

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

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

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

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

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

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

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

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

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