5. Життєвий цикл сторінки asp.Net

Нехай у нас існує сторінка з кнопкою (Button) "Відправити" і текстовим полем (TextBox) без автоматичної зворотної відправки. При зміні тексту в текстовому полі і натисненні на кнопці "Відправити" ініціюється зворотна відправка даних сторінки на сервер (цього не відбулося при зміні тексту в текстовому полі, так як відповідна опція цього елементу управління AutoPostBack встановлена false). У момент зворотної відправки сторінки на сервер ASP.NET запускає наступні події:

          Page.Init.

          Page.Load.

          TextBox.TextChanged.

          Button.Click.

          Page.PreRender.

          Page.Unload.

У результаті обробки всіх ініційованих подій генерується HTML-код сторінки, який і передається клієнту, після чого виконується очищення, в рамках якого ініціюється подія Page_Unload. Воно призначене для звільнення ресурсів, зайнятих цією сторінкою. Подія Page.PreRender ініціюється після того, як сервер обробив усі події сторінки, але генерація її HTML-коду ще не відбулася. Зазвичай ця подія використовується ASP.NET для прив'язки елементів управління до джерел даних безпосередньо перед створенням HTML-коду і відправкою його клієнту.

Описана послідовність подій дозволяє створити опис життєвого циклу Web-сторінки, зображеного на рис. 5.8.

Повернімося, до проблеми збереження даних сторінки в проміжку між зверненнями до неї. Для реалізації цього механізму в ASP.NET використовується стан відображення (view state). Стан відображення Web-форми доступний тільки всередині цієї Web-форми. Якщо необхідно зробити дані, введені в Web-форму, доступними для інших Web-форм одного і того ж додатка, ці дані необхідно зберегти в об'єктах з більш глобальною областю видимості, які називають змінними стану.

 

Рисунок 5.8 – Життєвий цикл web-сторінки

 

Об'єктів змінних станів два: Application і Session. Змінні стану Application доступні всім користувачам програми і можуть розглядатися як глобальні змінні, звернення до них можливе з будь-яких сеансів. Змінні стану Session доступні тільки в рамках одного сеансу, і тому вони доступні лише одному користувачеві. У змінних стану можна зберігати дані будь-якого типу. В силу того, що змінні стану фактично є глобальними змінними, для роботи з ними бажано виробити стратегію їх використання у додатку.

Лекція №6. Технологія MVC

 

Оскільки розробка сайтів продовжує розвиватися, з'являються нові вражаючі способи проведення цієї роботи. Одним з найсвіжіших (і найбільш вражаючих) нововведень стало застосування архітектурного шаблону "модель-представлення-контролер" (Model-View-Controller - MVC) до веб-сайтів. Але цей шаблон далеко не новий.

 

1 Історія створення

Термін "модель-представлення-контролер" використовується з кінця 70-х років минулого сторіччя. Ця модель стала результатом проекту Smalltalk в компанії Xerox PARC, де вона була задумана як спосіб організації деяких з ранніх додатків графічного інтерфейсу користувача. Деякі з нюансів початкової моделі MVC були пов'язані з концепціями, специфічними для Smalltalk, такими як екрани та інструменти, але більш глобальні поняття все ще застосовні до додатків, і особливо добре вони підходять для веб-додатків.

Взаємодії з додатком MVC здійснюється відповідно з природним циклом дій користувача і оновлень представлення, при якому передбачається, що представлення не містить інформації про стан. Це прекрасно поєднується із запитами та відповідями HTTP, які підкріплюють веб-додаток.

Більше того, MVC змушує до поділу відповідальності - модель предметної області і логіка контролера відокремлені від користувача інтерфейсу. У веб-додатку це означає, що суміш HTML-розмітки міститься окремо від решти частини програми, що спрощує і полегшує супровід і тестування. Поява платформи Ruby on Ralls призвело до відновлення загального інтересу до MVC, і вона залишається рекламним плакатом моделі MVC. З тих пір з'явилося багато інших платформ MVC, які продемонстрували вигоди MVC - зрозуміло, це відноситься і до ASP.NET MVC.

 

 

 

2 Особливості архітектурного шаблону MVC

Якщо оперувати поняттями високого рівня, архітектурний шаблон MVC означає, що додаток MVC буде розділено, принаймні, на три частини.

       Моделі, що містять або представляють дані, з якими працюють користувачі. Вони можуть бути простими моделями уявлень, які тільки представляють дані, які передаються між представленнями і контролерами; або ж вони можуть бути моделями предметної області, які містять бізнес-дані, а також операції, перетворення і правила для маніпулювання цими даними.

       Представлення, що застосовуються для візуалізації деякої частини моделі у вигляді інтерфейсу користувача.

       Контролери, які обробляють запити, що надходять, виконують операції з моделлю і вибирають представлення для візуалізації користувачеві.

Моделі - це визначення "всесвіту", в якому працюють наші програми. Наприклад, в банківському додатку модель представляє всі аспекти банківської діяльності, підтримувані додатком, такі як розрахункові рахунки, головна бухгалтерська книга і кредитні ліміти для клієнтів, так само як і операції, які можуть використовуватися для маніпулювання даними в моделі, такі як внесення грошових коштів та списання з рахунків. Модель відповідає також за збереження загального стану і цілісності даних. Наприклад, засвідчити, що всі транзакції внесені в бухгалтерську книгу, і що клієнт не знімає з рахунку більше грошових коштів, ніж має на те право, або більше, ніж банк має у своєму розпорядженні.

Моделі визначені також тим, за що вони не відповідають. Моделі не мають справу з візуалізацією користувацьких інтерфейсів або обробкою запитів, так як це обов'язок представлень і контролерів. Представлення містять логіку, необхідну для відображення елементів моделі користувачеві, і нічого більше. Вони не мають ніякого безпосереднього уявлення про моделі, і ніяк не обмінюються даними безпосередньо з нею. Контролери є сполучною ланкою між представленням і моделлю. Запити надходять від клієнта і обслуговуються контролером, який вибирає відповідне представлення для відображення користувачеві і, якщо потрібно, відповідну операцію, яка повинна бути виконана по відношенню до моделі.

Кожна частина архітектури MVC є чітко визначеною і автономною - цей підхід називають поділом відповідальності. Логіка, яка маніпулює даними в моделі, міститься тільки в моделі, логіка, що відображає дані - тільки в відображенні, а код, який обробляє запити і введення користувачів - тільки в контролері. При чіткому розмежуванні всіх частин додаток буде легше супроводжувати і розширювати протягом його терміну існування, незалежно від того, наскільки великим він стане.

 

2.1 Модель предметної області

Найбільш важливою частиною програми MVC є модель предметної області. Ця модель створюється за рахунок визначення реальних об'єктів, операцій і правил, що існують у даній галузі або роді діяльності, які має підтримувати додаток. Ця сукупність називається предметною областю.

Після цього створюється програмне представлення предметної області - модель предметної області. Для наших цілей модель предметної області - це набір типів С# (класів, структур і т.д.), які узагальнено називатимуться типами предметної області. Операції з предметної області представляються методами, визначеними в типах предметної області, а правила предметної області виражаються логікою, укладеної всередині цих методах, або за допомогою застосування атрибутів C# до методів. Створюючи екземпляр типу предметної області для представлення конкретної частини даних, тим самим ми створюємо об'єкт предметної області. Зазвичай моделі предметної області стійкі і довговічні. Існує безліч різних способів досягнення цього, але реляційні бази даних залишаються найбільш поширеним варіантом.

Модель предметної області - це єдине, що заслуговує повної довіри визначення бізнес-даних і процесів у рамках програми. Стійка модель предметної області є також авторитетним визначенням стану подання предметної області.

Підхід із застосуванням моделі предметної області вирішує багато проблем, що виникають в рамках шаблону "інтелектуального" ​​інтерфейсу користувача. Вся бізнес-логіка міститься в одному місці. При виникненні необхідності маніпулювання даними в моделі або додавання нового процесу або правила модель предметної області - єдина частина програми, яку доведеться змінити.

 

2.2 ASP.NET-реалізація  MVC

У MVC контролери є класами С#, зазвичай похідними від класу System.Web.Mvc.Controller. Кожен метод public в класі, успадкованому від класу Controller, називається методом дії і за допомогою системи маршрутизації ASP.NET пов'язаний з конфігурованим URL. Коли запит відправляється URL, пов'язаному з методом дії, оператори в класі контролера виконуються, щоб провести деяку операцію стосовно моделі предметної області і потім вибрати представлення для відображення клієнту. Взаємодії між контролером, моделлю і представленням показані на рисунку 2.1.

 

Рисунок 2.1 – Взаємодія в додатку MVC

 

Платформа ASP.NET MVC надає підтримку для вибору механізмів візуалізації. У більш ранніх версіях MVC використовувався стандартний механізм візуалізації ASP.NET, який обробляв ASPX-сторінки із застосуванням оптимізованої версії синтаксису розмітки Web Forms. У платформі MVC 3 був введений механізм візуалізації Razor, який використовує зовсім інший синтаксис. Visual Studio забезпечує підтримку засобу IntelliSense для обох механізмів візуалізації, максимально спрощуючи впровадження і відповідь на дані представлення, надані контролером.

ASP.NET MVC не накладає ніяких обмежень на реалізацію моделі предметної області. Можна створити модель за допомогою звичайних об'єктів C# і реалізувати сталість, використовуючи будь-яку з баз даних, платформ ORM або інших інструментів роботи з даними, підтримуваних. NET. Visual Studio створює папку /Models як частину шаблону проекту MVC. Це підходить для простих проектів, але для більш складних додатків характерно визначення їх моделей предметної області в окремому проекті Visual Studio.

 

2.3 Слабке зв’язування

Одна з найбільш важливих особливостей моделі MVC полягає в тому, що вона робить можливим поділ відповідальності. Нам потрібно, щоб компоненти в нашому додатку були максимально незалежними один від одного і мали лише таку кількість взаємозалежностей, яким ми зможемо керувати.

В ідеалі кожен компонент нічого не знає про будь-який інший компонент і взаємодіє з іншими областями програми лише за допомогою абстрактних інтерфейсів. Така взаємозалежність називається слабким зв'язуванням, і вона спрощує тестування і модифікування додатки.

Простий приклад допоможе розумінню цього підходу. Якби ми створювали компонент MyEmailSender, призначений для відправки повідомлень електронної пошти, ми б реалізували інтерфейс, що визначає всі загальнодоступні функції, необхідні для відправки електронної пошти, який можна було б назвати IEmailSender.

Тоді будь-який інший компонент нашого додатку, якому потрібно надіслати повідомлення електронної пошти - наприклад, допоміжний метод скидання пароля PasswordResetHelper - може відправити повідомлення, звертаючись тільки до методів, визначеним всередині інтерфейсу. Як видно на рисунку 2.2, ніякої прямої залежності між PasswordResetHelper іMyEmailSender не існує.

 

Рисунок 2.2 – Використання інтерфейсів для роз’єднання компонентів

 

Вводячи інтерфейс IEmailSender, ми гарантуємо відсутність будь-якої прямої залежності між PasswordResetHelper іMyEmailSender. Компонент MyEmailSender можна було б замінити іншим постачальником електронної пошти або навіть використовувати фіктивну реалізацію з метою тестування.

 

2.4 Помилки при користуванні MVC

Розглянемо найбільш поширені помилки, які бувають при користуванні MVC.

 

2.4.1 Перевантажений Контролер

Деякі розробники помилково трактують Модель тільки як засіб доступу до бази даних. У результаті бізнес-логіка переходить у Контролер, що в корені суперечить архітектурі MVC.

Варто пам'ятати, що Модель це не тільки доступ до даних, але і логіка програми, перевірка одержуваних від користувача даних і т. д. У свою чергу, Контролер - сполучна ланка між нею, Представленням і користувачем.

 

2.4.2 Перевантажена Модель

Іншою помилкою є спроба перенести всю логіку в Модель. Подібну помилку часто можна зустріти при розробці веб-додатків. У цьому випадку Представлення намагаються перетворити на простий шаблон, доступний для редагування будь-якому верстальщику. При цьому логіка елементів інтерфейсу користувача з Представлення переміщається в Модель чи, іноді, в Контролер.

Даний підхід є помилковим з точки зору архітектури MVC, тому що порушується чіткий поділ компонентів: Модель стає залежна від Представлення.

При правильному підході, логіка користувача інтерфейсу повинна знаходитися в Представлення. Але при цьому важливо коректно розділити її та бізнес-логіку.

 

3 Принципи функціонування ASP.NET MVC

У Visual Studio створимо новий проект і почнемо розробляти сайт, використовуючи архітектуру MVC. Серед бібліотек .NET є відмінна основа для такого завдання - Microsoft ASP.NET MVC.

Microsoft ASP.NET MVC це каркас (framework) для розробки веб-додатків в рамках архітектури Model-View-Controller. Він бере на себе реалізацію безлічі стандартних функцій, пов'язаних з архітектурою. Це дозволяє розробнику зосередитися безпосередньо на створенні коду самого програми - бізнес-логіки й користувальницького інтерфейсу.

Для вивчення роботи ASP.NET MVC 3 створимо проект BookCatalog. Як шаблон виберемо ASP.NET MVC 3 Web Application і у вікні вкажемо наступні параметри (рисунок 3.1):

        потрібен порожній проект (Empty);

        можна використовувати HTML5 в шаблонах;

        движком представлень буде Razor.

Не дивлячись на назву "порожній", підготовлений середовищем Visual Studio новий проект не виглядає як порожня папка. До нього вже додані:

        бібліотеки jQuery, modernizr (використовується для спрощення підтримки старих версій браузерів без HTML5) іMicrosoft Ajax;

        посилання (reference) на Entity Framework;

        шаблон розмітки для Представлень;

        стандартні для ASP.NET файли Global.asax і Web.config.

 

 

Рисунок 3.1 – Створення проекту

 

Також створені папки для наступних файлів:

        Content - для елементів дизайну користувальницького інтерфейсу (CSS і графічні файли);

        Controllers - класи Контролерів;

        Models - класи Моделі;

        Scripts - місце зберігання JavaScript файлів;

        Views - шаблони Представлень.

ASP.NET MVC 3 підключає перераховані вище бібліотеки використовуючи NuGet. Це означає, що надалі можна при необхідності буде легко їх оновити. Локальний репозиторій розташований в папці packages на рівні папки проекту.

Як було сказано раніше, цикл роботи MVC програми починається з Команди. Він передається Контролеру, який вибирає Модель для обробки запиту і Представлення для виведення результату. Розглянемо як це все виглядає в ASP.NET MVC.

 

3.1 Команда

Командою для веб-додатка є звернення за певною адресою на сайті.

Тут варто відзначити, що може існувати кілька Контролерів. Це не суперечить архітектурі MVC, але вимагає механізму вибору з них потрібного для отриманої команди. Каркас ASP.NET MVC для цієї мети використовує набір маршрутів, які реєструються в методі RegisterRoutes(), розташованому у файлі Global.asax.

Створення та встановлення маршрутів це окрема і досить велика тема. Тому зараз, для вивчення принципів роботи, розглянемо тільки простий варіант. Наприклад, той який вже заданий за замовчуванням у створеному проекті:

 

routes.MapRoute(

"Default", // Route name

"{controller}/{action}/{id}", // URL with parameters

new { controller = "Home", action = "Index", id = UrlParameter.Optional } // Defaults

);

 

Як видно з наведеного вихідного коду, для завдання маршруту використовується метод MapRoute(). Йому передаються три наступні параметри:

        ім'я створюваного маршруту;

        шаблон URL адреси маршруту, що розділяє його на складові;

        об'єкт, що містить значення за замовчуванням.

Наведене правило за замовчуванням вважає, що посилання містить назву Контролера {controller}, ім'я методу Дії{action} і додатковий параметр {id}. При відсутності частини даних у вихідному запиті будуть використовуватися значення за замовчуванням: Контролер Home і Дія Index, а параметр id відзначений як не обов'язковий.

Дія – це метод Контролера, який викликається для обробки команди і готує дані для Представлення. Результат, як правило, повертається у вигляді одного з нащадків класу ActionResult.

Подивимося до якого методу якого класу звернутися каркас ASP.NET MVC на простому прикладі:http://www.somesite.com/Home/Edit/42. Зіставивши з шаблоном "{controller}/{action}/{id}" можна відразу сказати, що буде використовуватися Контролер Home і Дія Edit, а додатковий параметр дорівнює 42. У результаті ядро ASP.NET MVC створить екземпляр класу HomeController і викличе метод Edit() c одним параметром, передавши йому значення 42. Зверніть увагу на підставлення закінчення Controller в ім'я класу.

Що станеться якщо зазначені клас або метод знайти не вдасться? Буде виведено повідомлення про помилку і обробка команди на цьому буде завершена.

Можлива ситуація, коли в класі визначені кілька методів з однаковим ім'ям. Тоді для Дії вибирається найбільш відповідний переданим параметрами. Наприклад є два методи: Action() і Action(string userId). Тоді за відсутності в запиті параметра буде викликаний перший з них, а за наявності - другий. При цьому визначати додаткове правило для маршруту без опціонального параметра не потрібно.

Якщо в посиланні відсутня частина даних, то ASP.NET MVC буде підставляти значення за замовчуванням. Це ті самі значення, які були передані в третьому параметрі методу реєстрації маршруту MapRoute(). Наприклад, дляhttp://www.somesite.com/Users/ буде викликаний Контролер Users з Дією за замовчуванням (Index). А для запитуhttp://www.somesite.com/ будуть використані як Контролер за замовчуванням (Home), так і Дія (Index).

 

3.2 Контролер

Після того, як каркас ASP.NET MVC визначив використовувані Контролер і Дію, він передає йому команду для обробки. Сам Контролер в коді Дії звертається до однієї або декількох Моделей і повертає отриманий від них результат в Представлення. Він містить певну логіку вибору, але як було зазначено раніше, не повинен містити бізнес-логіку.

Файли Контролерів розташовуються в папці Controllers. Імена їх класів мають закінчення Controller.

 

3.3 Модель

Для файлів Моделей так само є своє місце в загальній структурі - папка Мodels. Саме тут розміщується вся бізнес-логіка програми - алгоритми, правила, роботи з базою даних і т.д.

Серед всіх об'єктів даної групи можна виділити класи описують дані для передачі в Представлення. Як правило, вони складаються тільки з властивостей. Саме ці класи зазвичай маються на увазі під словом "Модель", коли говорять про Моделі, переданих в Представлення. Для них у прикладах будемо використовувати закінчення Мodel, щоб виділити їх на фоні класів безпосередньо бізнес-логіки.

ASP.NET MVC надає механізм для контролю коректності даних, що містяться в Моделях. Він заснований на завданні властивостям атрибутів, що встановлюють їх допустимі величини.

 

3.4 Представлення

Спрощено кажучи, Представлення – це шаблони майбутніх сторінок. Але, в порівнянні зі звичайними веб-сторінками, з розширеним синтаксисом. Додаткові можливості необхідні для відображення отриманих від Моделі даних і управління цим процесом.

Для перетворення Представлень в HTML код ASP.NET MVC використовує движки представлень. У вихідну поставку їх входить два: знайомий багатьом WebForms і Razor, що з'явився в MVC 3. Крім того, розробники можуть створювати і підключати власні реалізації. Варто відзначити, що в одному проекті можуть спільно використовуватися кілька движків представлень.

Файли Представлень розташовуються у своїй папці під назвою Views. Оскільки використовується движок уявленьRazor, то вони мають розширення cshtml (для C#) або vbhtml (для Visual Basic). Розглянемо вміст папки детальніше:

       файл _ViewStart.cshtml задає код, який буде виконаний перед викликом будь-якого Представлення. Наприклад, у ньому вказується шаблон розмітки сторінок за замовчуванням.

       папка Shared містить загальні Представлення, доступні всім Контролерам. Тут розташовані:

1)    шаблони розмітки, які дозволяють задавати єдину компоновку для виведених сторінок. Типово таким шаблоном є _Layout.cshtml.

2)    Представлення Error.cshtml, яке використовується для виведення повідомлення про помилку.

У ASP.NET MVC діє наступне узгодження: Контролер використовує Представлення з файлу з ім'ям як у Дії, розташований в папці з ім'ям як у Контролера. Наприклад, для адреси http://www.somesite.com/Home/Edit/42 буде використовуватися Представлення з файлу Edit.cshtml, розташованого в папці Views/Home. Однак при необхідності Контролер може явно задати ім'я потрібного йому Представлення.

У якості підсумку, подивимося на дії движка уявлень при зверненні до сторінкиhttp://www.somesite.com/Home/Edit/42:

1)    викликається код, розташований у файлі _ViewStart.cshtml;

2)    при використанні шаблону розмітки здійснюється його пошук і обробка;

3)    в папці, з ім'ям Home здійснюється пошук файлу Edit.cshtml/Edit.vbhtml;

4)    за відсутності файлу ASP.NET MVC намагається виявити його в папці Shared;

5)    якщо файл знайдений, то створюється HTML і завершується обробка;

6)    якщо файл не виявлений - видається повідомлення про помилку.