Кожен запит, що надходить в додаток, обробляється контролером. Контролер може обробляти запит довільним чином до тих пір, поки він не перетинає кордон відповідальності моделі та подання. Це означає, що контролери не повинні містити або зберігати дані, так само як і генерувати призначені для користувача інтерфейси.
В інфраструктурі ASP.NET MVC Framework контролери є класами .NET, які містять логіку, необхідну для обробки запиту. Роль контролера полягає в інкапсуляції логіки додатка. Іншими словами, контролери відповідають за обробку вхідних запитів, виконання операцій над моделлю предметної області і вибір уявлень для візуалізації користувачеві.
приклад програми
Для цілей цієї і наступних статей ми створимо новий проект MVC на ім'я ControllersAndActions з використанням шаблону Empty (Порожній), зазначивши прапорець MVC в розділі Add folders and core references for (Додати папки і основні посилання для), а також проект модульного тестування під назвою ControllersAndActions .Tests. Модульні тести, які будуть створюватися, не вимагають імітованих реалізацій, тому пакет Moq встановлювати не доведеться, але потрібно встановити пакет MVC, щоб тести мали доступ до базових класів контролерів.
У вікні консолі диспетчера пакетів NuGet середовища Visual Studio введіть наступну команду:
поняття контролера
Створення контролера за допомогою інтерфейсу IController
У MVC Framework класи контролерів повинні реалізувати інтерфейс IController з простору імен System.Web.Mvc. показаний в прикладі нижче:
Щоб отримати визначення цього інтерфейсу, необхідно завантажити вихідний код MVC Framework. який надзвичайно корисний для з'ясування внутрішньої роботи засобів інфраструктури.
Як бачите, інтерфейс IController дуже простий. Його єдиний метод Execute () викликається, коли запит направляється цього класу контролера. Інфраструктура MVC Framework з'ясовує, на який клас орієнтований запит, за рахунок читання значення властивості controller, згенерованого даними маршрутизації, або через спеціальні класи маршрутизації.
Створювати класи контролерів можна шляхом реалізації інтерфейсу IController, однак оскільки цей інтерфейс є низькорівневим, потрібно виконати чимало роботи, щоб отримати, в кінцевому рахунку, що-небудь корисне. Проте, інтерфейс IController корисний для демонстрації оперування контролерів і з цією метою в папці Controllers створюється новий файл класу на ім'я BasicController.cs, вміст якого наведено в прикладі нижче:
Методу Execute () інтерфейсу IController передається об'єкт RequestContext. надає інформацію про поточний запиті і маршруті, який йому відповідає (і призводить до виклику даного контролера для обробки цього запиту). У класі RequestContext визначені два властивості, описані в таблиці нижче:
Властивості, що визначаються класом RequestContext
Повертає колекцію значень сегментів, індексовану на ім'я
У статті Налаштування системи маршрутизації було показано, як використовувати типи RouteBase і IRouteHandler для настройки системи маршрутизації. У розглянутому прикладі за допомогою властивості Values виходять значення змінних сегментів controller і action, які потім записуються в відповідь.
Частина проблеми, що виникає при створенні спеціальних контролерів, пов'язана з відсутністю доступу до таких засобів, як уявлення. Це означає, що доведеться працювати на більш низькому рівні, чим і пояснюється запис вмісту безпосередньо у відповідь клієнту. Властивість HttpContextBase.Response повертає об'єкт HttpResponseBase. який дозволяє конфігурувати і додавати вміст до відповіді, призначеному для відправки клієнтові. Це ще одна точка дотику між платформою ASP.NET і інфраструктурою MVC Framework.
Якщо запустити додаток і перейти на URL виду / Basic / Index, то спеціальний контролер згенерує висновок, показаний на малюнку нижче:
Реалізація інтерфейсу IController дозволяє створити клас, який MVC Framework розпізнає як контролер і відправляє йому запити, без жодних обмежень щодо того, як запит обробляється, і яку відповідь для нього генерується. Це вдалий приклад, оскільки він показує, наскільки розширюється може бути інфраструктура MVC Framework навіть для ключових будівельних блоків на кшталт контролерів, однак написання складного додатка подібним чином може бути пов'язане з чималими труднощами.
Класи з іменами, що закінчуються на Base
При обробці запитів інфраструктура MVC Framework покладається на платформу ASP.NET, що має великий сенс, тому що ця платформа є перевіреною і багатофункціональної реалізацією, яка тісно інтегрується з сервером додатків IIS. Проблема полягає в тому, що класи, які застосовуються платформою ASP.NET для надання інформації про запити, не дуже добре підходять для модульного тестування - основного переваги використання MVC Framework.
У Microsoft вирішили ввести можливість тестування, підтримуючи при цьому сумісність з існуючими додатками ASP.NET Web Forms, так що в результаті з'явилися класи Base. Ці класи так називаються через те, що вони мають ті ж самі імена, як у основних класів платформи ASP.NET, за якими слід слово Base.
Так, наприклад, платформа ASP.NET надає контекстну інформацію про поточний запиті і ряді ключових служб додатки через об'єкт HttpContext. Відповідним йому класом Base є HttpContextBase, екземпляр якого передається методу Execute (), визначеного в інтерфейсі IController (в наступних прикладах будуть продемонстровані і інші класи Base). У початкових класах і класах Base визначені одні і ті ж властивості і методи, але класи Base завжди абстрактні. а це значить, що їх легко застосовувати для модульного тестування.
Іноді ви отримаєте екземпляр одного з початкових класів ASP.NET, такого як HttpContext. В такому випадку необхідно створити дружній до MVC клас Base, подібний HttpContextBase. Це робиться з використанням одного з класів Wrapper. які мають такі ж імена, як початкові класи, доповнені словом Wrapper, наприклад, HttpContextWrapper. Класи Wrapper є похідними від класів Base і мають конструктори, які приймають екземпляри первинних класів:
Початкові класи, класи Base і класи Wrapper визначені в просторі імен System.Web, тому платформа ASP.NET може гладко підтримувати додатки MVC Framework і старіші додатки Web Forms.
Створення контролера за рахунок успадкування від класу Controller
Як було продемонстровано в попередньому прикладі, інфраструктура MVC Framework допускає практично необмежену настройку і розширення. Щоб забезпечити будь-який необхідний вид обробки запитів та генерації результатів, можна реалізувати інтерфейс IController. Вам не подобаються методи дій? Ви не хочете турбуватися з приводу візуалізованими уявлень? В такому випадку можете взяти справу в свої руки і реалізувати кращий, швидкий і більш елегантний спосіб обробки запитів. Або ж ви можете скористатися засобами, пропонованими командою розробників MVC Framework з Microsoft, і успадкувати свої контролери від класу System.Web.Mvc.Controller.
Поведінка контролера рознесено по безлічі методів (замість реалізації у вигляді єдиного методу Execute ()). Кожен метод дії відображається на відповідний URL і викликається з параметрами, витягнутими з вхідного запиту.
Можна повертати об'єкт, що описує результат виконання дії (наприклад, візуалізація уявлення або перенаправлення на інший URL або метод дії), і потім обробляти його яким завгодно чином. Поділ між зазначенням результатів і їх виконанням спрощує модульне тестування.
Багаторазово використовується поведінку (наприклад, аутентифікацію) можна инкапсулировать у вигляді фільтрів і потім позначати кожен аспект поведінки контролерів і методів дій за допомогою атрибута в вихідному коді.
Якщо тільки ви не маєте справу з специфічним вимогою, то найкращим підходом до створення контролерів буде їх успадкування від класу Controller, що, як і можна було очікувати, роблять середовище Visual Studio, коли створює новий клас у відповідь на вибір пункту меню Add -> Scaffold (Додати -> Шаблон).
У прикладі нижче наведено код простого контролера під назвою DerivedController, створеного подібним чином. Він згенерований із застосуванням варіанти MVC 5 Controller - Empty (Контролер MVC 5 - Порожній) з кількома простими змінами, призначеними для установки властивості ViewBag і вибору уявлення:
Клас Controller також забезпечує зв'язок з системою уявлень Razor. У цьому прикладі ми повертаємо результат виклику методу View (), якому в якості параметра передається ім'я уявлення для візуалізації клієнту. Щоб створити цей спектакль, створіть папку Views / Derived, клацніть на ній правою кнопкою миші і виберіть в контекстному меню пункт Add -> MVC 5 View Page (Razor) (Додати -> Сторінка уявлення MVC 5 (Razor)). Вкажіть в якості імені MyView.cshtml і клацніть на кнопці ОК для створення файлу уявлення.
Наведіть вміст файлу у відповідність з прикладом:
Після запуску програми і переходу на URL виду / Derived / Index цей метод дії викликається, а подання MyView візуалізується:
