Що таке "життєвий цикл сторінки" сторінки 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, натомість ваші класи контролерів та методи їх дії будуть обробляти завантаження ваших даних у "модель", яка передається перегляду.

Хоча прив'язка даних у стилі веб-форми можлива в MVC, я вважаю, що це не оптимальне рішення. Краще розмістити свої дані в модельному класі та сильно набрати свій погляд, щоб мати прямий доступ до цієї моделі. Тоді просто питання використання <%= ViewData.Model.SomeProperty %>синтаксису для доступу до даних та відображення їх у потрібних місцях. Що стосується огляду, моя рекомендація - забути, що вона навіть існує.

Пам'ятайте, що однією з переваг використання MVC є те, що ви маєте контроль над HTML, який ви надсилаєте клієнту. Візьміть на себе цю силу і спробуйте знайти рішення, які дозволять вам підтримувати цей контроль. Елементи керування веб-формою намагаються приховати html від вас і тому ускладнюють налаштування html, коли потрібно.

Я б дуже рекомендував JQuery або іншу подібну потужну бібліотеку javascript. Але навчіться використовувати їх для прямого доступу до HTML DOM та уникайте проблем із керуванням id управліннями веб-форми.

Ви можете використовувати jquery для підключення до випадаючого вибору на стороні клієнта та подання стандартних запитів або запитів у стилі ajax. Ці запити можуть повернути нові сторінки, переадресації, фрагменти html або навіть дані JSON, які можна використовувати для оновлення існуючої сторінки.

Сесія asp.net може використовуватися за потреби.