No Image

Шаблоны asp net mvc

СОДЕРЖАНИЕ
2 просмотров
22 января 2020

MVC трехсоставная концепция построения веб-сайтов. Аббревиатура MVC происходит от слов Model-View-Controller. MVC распространённый стиль создания сайтов сложной структуры основанная на четком разделении разных составляющих: дизайн, распределение запросов пользователей, программная логика. Каждую из составляющих удобно совершенствовать по отдельности сосредотачиваясь над однородной работой.

Вкратце об истории MVC. Впервые концепция была сформулирована и описана Трюгве Реенскаугом (норвежский ученый в сфере компьютерных наук и заслуженный профессор университета Осло) в 1979 году, работавшим в то время над языком программирования Smalltalk в Xerox PARC. Затем Джим Алтофф с командой разработчиков реализовали версию MVC для библиотеки классов Smalltalk-80.

И в настоящее время схема MVC широко распространена, и применяется в веб-разработках независимо от языка программирования, платформ и операционных систем. Функции частей MVC:

  • Model – программная обработка и обращение к базе данных вызванных запросом пользователя
  • View – выводит результат в требуемом виде, т.е. к одной модели можно прикрепить несколько разных представлений
  • Controller – распределяет внешние запросы пользователя между моделью и представлением

Практическая польза от создания сайтов на концепции MVC:

  • Упрощение работы над сложной структурой сайта;
  • Возможность сосредоточения в одном секторе программирования;
  • Возможность многократного использования отдельных частей приложения;
  • Небольшое количество шаблонов страниц позволяет создавать богатое разнообразное содержание сайта.

Используя схематику MVC изменить дизайн сайта или его логику работы гораздо проще и быстрее. Даже отдельный разработчик, не боясь запутаться в коде, может создавать веб-приложения высокой организованности. Работая в команде, прикладные программисты и веб-дизайнеры, будут чувствовать себя каждый в своей родной стихии.

Концепция MVC используется для многих платформ и языков программирования, не исключение и ASP.NET. В нашем случае мы будем говорить об MVC на языке C#. C# мощный язык программирования, специально созданный для платформы .NET, являясь языком прикладного уровня, предоставляет огромные возможности по сравнению с другими языками веб-разработок (php, perl, pyton, ruby). Одно из многих достоинств C# это то, что он играючи справляется с любыми кодировками и символами.

Самостоятельно создать шаблон MVC очень сложно, и если не задаваться целью создания собственного каркаса, лучше использовать шаблоны, созданные профессиональными программистами и включаемые в состав среды программирования Microsoft Visual Studio, тем более что эти шаблоны постоянно совершенствуются. Для отдельных разработчиков компания Microsoft предоставляет бесплатные интегрированные среды Visual Studio Express и Visual Studio Community, а для организаций – профессиональные инструменты с широчайшими возможностями это Visual Studio Professional и Visual Studio Enterprise.

В шаблоне MVC технологии ASP.NET в качестве модели выступают «обыкновенные классы» C#, создающие контент и получающие данные из базы данных. Название класса может быть любым, количество классов в модели тоже может быть любым, т.е. Модель это совокупность классов программной логики веб-приложения. Поскольку файлы модели это классы с языком C#, соответственно они имеют расширение .cs. Как уже было сказано выше, в модели происходит вся основная логическая работа, через контроллеры в представления передаются уже готовые данные. Некоторую часть программной обработки можно осуществлять и в методах контроллера.

Листинг №1 Модель приложения класс Animals

Контроллер это специальный класс языка C#, производный от базового класса Controller. Название каждого контроллера обязательно должно состоять из двух частей: имени и суффикса Controller, например HomeController, AnimalsController. Контроллеров в веб-приложении может быть несколько штук. Контроллер имеет методы, реагирующие на HTTP-запросы, направляемые на веб-сайт. Имена контроллеров и названия методов являются частями веб-адреса, например: http://domen/home(контроллер)/index(метод), http://domen/animals(контроллер)/dogs(метод). Файлы контроллеров имеют расширение .cs.

Листинг №2 Контроллер Animals

В качестве представлений выступают файлы с расширением .cshtml /.vbhtml с обработчиком Razor, позволяющий гармонично внедрять код языков .NET в код html. Основой синтаксиса Razor является знак @, после которого осуществляется переход к коду на языках C#/VB.NET. Также возможно использование и сторонних движков для представлений. Файлы .cshtml и .vbhtml в процессе генерации ответа контроллером компилируются в классы, из которых затем создается страница с чистым html кодом. Концепция MVC предписывает использовать минимальное количество кода C# и VB.NET в представлениях, поскольку вся основная программная обработка должна происходить в модели и контроллерах.

Листинг №3 Представление для метода Cats

В шаблон ASP.NET MVC встроена возможность создания человеко-понятных веб-адресов. При обработке запросов фреймворк ASP.NET MVC опирается на систему маршрутизации, которая сопоставляет все входящие запросы с определенными в системе маршрутами, указывающие какой контроллер и метод должен обработать данный запрос. Встроенный в шаблон маршрут по умолчанию предполагает трехзвенную структуру: контроллер/метод/параметр, а непосредственно адрес выглядит: домен/каталог(имя_контроллера)/раздел(название_метода)/параметр. Самостоятельно можно создавать любые структуры маршрутов.

Последовательность создания сайта на MVC в Visual Studio:

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

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

Так как большинство приложений так или иначе основываются на стандартных CRUD-операция (Create – Read – Update – Delete), то зачастую разработчики вынуждены многократно создавать контроллеры и представления для одних и тех же действий: добавления, изменения, удаления и просмотра записей из БД. И чтобы облегчить разработчикам жизнь, команда MVC добавила такую полезную функциональность, как шаблоны формирования (scaffolding templates). Эти шаблоны позволяют по заданной модели и контексту данных сформировать весь необходимый базовый код контроллеров, а также всю разметку для представлений, с помощью которых можно управлять записями в БД.

Читайте также:  0X80244010 ошибка обновления windows 7

Чтобы воспользоваться данной функциональностью, добавим новый контроллер. Нажмем правой кнопкой мыши на папку Controllers и выберем Add -> Controller. . Далее в окне добавления нового контроллера нам будет предложено выбрать шаблон контроллера:

Собственно к MVC относятся только первые три шаблона:

MVC 5 Controller – Empty . Этот шаблон добавляет в папку Controllers пустой контроллер, который имеет один единственный метод Index. Данный шаблон не создает представлений

MVC 5 Controller with read/write actions . Данный шаблон добавляет в проект контроллер, который содержит методы Index, Details, Create, Edit и Delete. Однако эти методы не содержат никакой логики работы с базой данных. И нам предлагается самим создать для них код и представления.

MVC 5 Controller with views, using Entity Framework . Это уже более интересный шаблон, который создает контроллер с методами Index, Details, Create, Edit и Delete, а также все необходимые представления для этих действий и добавляет код для извлечения информации из базы данных.

Выберем последний пункт, то есть MVC 5 Controller with views, using Entity Framework .

После этого откроется окно добавления нового контроллера, в котором нам будет предложено установить некоторые настройки:

Controller name : имя контроллера

Use async controller actions : будут ли автоматические сгенерированные методы контроллера асинхронными. Установим данную опцию.

Model class : класс модели. Выберем созданную ранее модель Book (либо какую-то другую имеющуюся модель)

Data context class : класс контекста данных. Выберем контекст данных для выбранной модели.

Generate views : надо ли генерировать представления к создаваемым действиям контроллера. При установке этой опции становятся доступными две следующие опции. Установим все эти опции.

Reference script libraries : будут ли подключать представления библиотеки jquery и другие необходимые файлы javascript

Use a layout page : будут ли генерируемые представления использовать мастер-страницу

Установив все опции, нажмем кнопку Add, и в проект будет добавлен новый контроллер. Он будет выглядеть примерно следующим образом:

А в папке Views/Book мы найдем все необходимые представления со всем необходимым кодом, который теперь нам не надо набирать вручную. И теперь мы можем запустить проект и перейти в адресной строке браузера к нашему контроллеру:

Благодаря шаблонам формирования мы можем не думать о создании кода для стандартных операций, что позволяет сэкономить уйму времени. Правда, после генерации кода все равно придется вносить правки, изменять автоматически сгенерированные названия на свои (например, название страницы, автоматические генерируемых ссылок и др.), однако от основной работы мы уже будем избавлены.

До появления инфраструктуры MVC Framework платформа ASP.NET предполагала наличие прямых отношений между запрашиваемыми URL и файлами на жестком диске сервера. Работа сервера заключалась в получении запроса от браузера и доставке вывода из соответствующего файла.

Такой подход хорошо работает для инфраструктуры Web Forms, в которой каждая страница ASPX представляет собой и файл, и самодостаточный ответ на запрос. Это не имеет смысла в приложении MVC, где запросы обрабатываются методами действий из классов контроллеров, и однозначное соответствие между запросами и файлами на диске отсутствует.

Для обработки URL в MVC платформа ASP.NET использует . В этой и последующих статьях мы покажем, как использовать систему маршрутизации для обеспечения мощной и гибкой обработки URL в разрабатываемых проектах. Вы увидите, что система маршрутизации позволяет создавать любой требуемый шаблон URL и выражать его в чистой и лаконичной манере. Система маршрутизации обеспечивает выполнение двух функций:

Исследование входящих URL и выяснение, для каких контроллеров и действий они предназначены. Как и следовало ожидать, это то, что система маршрутизации должна делать при получении клиентского запроса.

Генерация исходящих URL. Это URL, которые появляются в HTML-разметке, визуализированной из представлений, так что специфическое действие может быть инициировано, когда пользователь производит щелчок на ссылке (в этот момент ссылка снова становится входящим URL).

Пример приложения

Для демонстрации работы системы маршрутизации нам нужен проект, к которому мы сможем добавлять маршруты. Мы создали новое приложение MVC с использованием шаблона Empty (Пустой) и назвали проект UrlsAndRoutes. Кроме того, в решение Visual Studio добавлен тестовый проект по имени UrlsAndRoutes.Tests за счет отметки флажка Add unit tests (Добавить модульные тесты), как показано на рисунке ниже:

Создание модульных тестов вручную уже демонстрировалось в статьях, посвященных интернет-магазину GameStore, и в настоящий момент мы получаем аналогичный результат с автоматической поддержкой ссылок между проектами. Понадобится только добавить Moq, так что введите в окне консоли NuGet следующую команду:

Для демонстрации работы средства маршрутизации мы собираемся добавить в пример приложения несколько простых контроллеров. Нас интересует только способ, по которому URL интерпретируются с целью вызова методов действий, поэтому мы используем в качестве модели представлений строковые значения в объекте ViewBag, которые сообщают имена контроллера и метода действия.

Для начала создайте контроллер Home и приведите его код в соответствие с примером:

Читайте также:  Фильмы через smart tv

Создайте контроллер Customer с кодом, показанным в примере ниже:

Создайте контроллер по имени Admin и отредактируйте его согласно примеру:

Во всех методах действий этих контроллеров указано представление ActionName, что позволяет определить одно представление и применять его везде в примере приложения. Создайте внутри папки Views папку под названием Shared и добавьте в нее новый файл представления по имени ActionName.cshtml с содержимым, приведенным в примере ниже:

Как упоминалось ранее, среда Visual Studio пытается выяснить URL, запрашиваемый в браузере, на основе файла, который редактируется во время запуска отладчика. Это быстро начинает утомлять и данную функцию лучше отключить. Выберите пункт UrlsAndRoutes Properties (Свойства UrlsAndRoutes) в меню Project среды Visual Studio, в открывшемся диалоговом окне перейдите на вкладку Web и отметьте переключатель Specific Page (Определенная страница) в категории Start Action (Начальное действие). Вводить какое-либо значение не нужно – достаточно только выбора переключателя.

Запустив этот пример приложения, вы получите результат, показанный на рисунке ниже:

Введение в шаблоны URL

Система маршрутизации работает с использованием набора маршрутов. Эти маршруты вместе образуют схему URL, или схему для приложения, представляющую собой набор URL, которые приложение будет распознавать и реагировать на них.

Набирать вручную все индивидуальные URL, которые планируется поддерживать в приложении, не придется. Вместо этого каждый маршрут содержит шаблон URL, с которым сравниваются входящие URL. Если URL соответствует шаблону, он используется системой маршрутизации для обработки этого URL. Давайте начнем с URL для рассматриваемого примера приложения:

URL могут быть разбиты на сегменты. – это части URL за исключением имени хоста и строки запроса, которые отделяются друг от друга символом /. В приведенном выше примере URL имеются два сегмента, как показано на рисунке ниже:

Первый сегмент содержит слово Admin, а второй – слово Index. В глазах человека совершенно очевидно, что первый сегмент имеет отношение к контроллеру, а второй – к действию. Однако, естественно, это отношение должно быть выражено понятным для системы маршрутизации образом. Это делается с помощью следующего шаблона URL:

При обработке входящего запроса задача системы маршрутизации заключается в сопоставлении запрошенного URL с шаблоном и в последующем извлечении из URL значений для переменных сегментов, определенных в шаблоне. Переменные сегментов выражаются с использованием фигурных скобок (символов < и >). В приведенном примере шаблона определены две переменные сегментов с именами controller и action, поэтому значением переменной сегмента controller будет Admin, а значением переменной сегмента action – Index.

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

Системе маршрутизации ничего не известно о контроллерах и действиях. Она просто извлекает значения для переменных сегментов. Позже в процессе обработки запросов, когда запрос достигнет собственно инфраструктуры MVC Framework, производится присваивание этих значений переменным controller и action. Именно поэтому система маршрутизации может использоваться с инфраструктурами Web Forms и Web API.

По умолчанию шаблон URL будет соответствовать любому URL, который имеет подходящее количество сегментов. Например, шаблон "/" будет соответствовать любому URL с двумя сегментами, как показано в таблице ниже:

Сопоставление шаблона с URL

Переменные сегментов URL запроса
http://localhost:64399/Admin/Index controller = Admin, action = Index
http://localhost:64399/Index/Admin controller = Index, action = Admin
http://localhost:64399/Apples/Oranges controller = Apples, action = Oranges
http://localhost:64399/Admin Соответствия нет – сегментов слишком мало
http://localhost:64399/Admin/Index/Football Соответствия нет – сегментов слишком много

В этой таблице отражены два ключевых аспекта поведения шаблонов URL:

Шаблоны URL являются консервативными, и будут совпадать только с теми URL, которые имеют то же самое количество сегментов, что и шаблон. Это можно наблюдать в четвертом и пятом примерах в таблице.

Шаблоны URL являются либеральными. Если URL имеет правильное количество сегментов, шаблон извлечет значение для переменной сегмента, каким бы оно ни было.

Эти два стандартных аспекта поведения являются ключевыми в понимании функционирования шаблонов URL. Позже будет показано, как изменить такие стандартные аспекты поведения.

Как уже упоминалось, системе маршрутизации ничего не известно о приложении MVC, поэтому шаблоны URL будут давать совпадение, даже если для значений, извлеченных из URL, нет соответствующих контроллеров или действий. Это демонстрируется во втором примере в таблице. Здесь в URL сегменты Admin и Index поменялись местами, и также поменялись местами извлеченные из URL значения, хотя в действительности контроллер Index в рассматриваемом примере приложения не существует.

Создание и регистрация простого маршрута

Имея в виду шаблон URL, его можно использовать для определения маршрута (Route). Маршруты определяются в файле RouteConfig.cs, который находится в папке App_Start проекта. Начальное содержимое, определяемое Visual Studio для этого файла, показано в примере:

Статический метод RegisterRoutes(), определенный в файле RouteConfig.cs, вызывается из файла Global.asax.cs, который настраивает ряд основных средств MVC при запуске приложения. Стандартное содержимое файла Global.asax.cs приведено в примере ниже:

Метод Application_Start() вызывается лежащей в основе платформой ASP.NET, когда приложение MVC запускается в первый раз, что приводит к вызову метода RouteConfig.RegisterRoutes(). Параметром этого метода является значение статического свойства RouteTable.Routes, представляющее собой экземпляр класса RouteCollection, который вскоре будет описан.

Читайте также:  Что это индекс платежного адреса

Вызов метода AreaRegistration.RegisterAllAreas(), производимый внутри метода Application_Start(), настраивает связанное средство, называемое областями, которое рассматривается позже.

В примере ниже показано, как создать маршрут с использованием примера шаблона URL из предыдущего раздела в методе RegisterRoutes() внутри файла RouteConfig.cs (Чтобы можно было сосредоточиться только на текущем примере, все остальные операторы этого метода были удалены.)

Мы создаем новый объект Route, передавая его конструктору в качестве параметра шаблон URL, который выражен в виде строки. Кроме того, конструктору передается экземпляр MvcRouteHandler. Разные технологии ASP.NET предоставляют различные классы для настройки поведения маршрутизации, и MvcRouteHandler – это класс, предназначенный для приложений ASP.NET MVC. Созданный маршрут добавляется к объекту RouteCollection с помощью метода Add().

Более удобный способ регистрации маршрутов предусматривает применение метода MapRoute(), определенного в классе RouteCollection. В примере ниже показано, как зарегистрировать наш маршрут с помощью этого метода; результат будет таким же, как в предыдущем примере, но используемый синтаксис намного яснее:

Этот подход несколько компактнее, в основном потому что не приходится создавать экземпляр класса MvcRouteHandler (это делается автоматически). Метод MapRoute() предназначен исключительно для применения с приложениями MVC Приложения ASP.NET Web Forms могут пользоваться методом MapPageRoute(), который также определен в классе RouteCollection.

Использование простого маршрута

Увидеть эффект от внесенных в маршрутизацию изменений можно, запустив пример приложения. Когда попробовать в браузере перейти на корневой URL для приложения, возникнет ошибка – но если переходить по маршруту, соответствующему шаблону /, получается результат, подобный показанному на рисунке:

Наш простой маршрут не сообщает MVC Framework о том, как реагировать на запросы корневого URL, и поддерживает только единственный весьма специфический шаблон URL. Мы должны временно забыть о функциональности, которую Visual Studio добавляет в файл RouteConfig.cs при создании проекта MVC. В следующих статьях мы покажем, как строить более сложные шаблоны и маршруты.

Модульное тестирование: тестирование входящих URL

Рекомендуется проводить модульное тестирование маршрутов, чтобы удостовериться в корректной обработке ими входящих URL, даже если решено не выполнять модульное тестирование для остальной части приложения. В крупных приложениях схемы URL могут быть весьма сложными, и очень просто создать что-нибудь приводящее к неожиданным результатам.

Ранее мы избегали создания общих вспомогательных методов для совместного использования в разных тестах, стараясь сохранить каждый модульный тест самодостаточным. Здесь же мы примем другой подход. Тестирование схемы маршрутизации для приложения наиболее легко проводить, когда множество тестов упакованы в один метод, и это сделать намного проще с помощью ряда вспомогательных методов.

Для тестирования маршрутов необходимо создать имитации трех классов из MVC Framework: HttpRequestBase, HttpContextBase и HttpResponseBase. (Последний класс требуется для тестирования исходящих URL, которые будут рассматриваться позже.) Вместе эти классы воссоздают достаточную часть инфраструктуры MVC для поддержки системы маршрутизации.

Мы добавили в проект модульного тестирования UrlsAndRoutes.Tests новый файл модульных тестов по имени RouteTests.cs. Первым определением в нем является вспомогательный метод, который создает имитированные объекты HttpContextBase, как показано ниже:

На самом деле код только выглядит сложным. Тестируемый URL указывается в свойстве AppRelativeCurrentExecutionFilePath класса HttpRequestBase, а HttpRequestBase – в свойстве Request имитированного класса HttpContextBase. Следующий вспомогательный метод позволяет протестировать маршрут:

Параметры этого метода позволяют указать тестируемый URL, ожидаемые значения для переменных сегментов controller и action, а также экземпляр object, содержащий ожидаемые значения для любых дополнительных переменных, которые были определены. Позже мы покажем, как создавать такие переменные. Мы также определим параметр для метода HTTP, который объясним в статье "Ограничение маршрутов".

При сравнении результата, полученного от системы маршрутизации, со значениями переменных сегментов, которые мы ожидаем, метод TestRouteMatch() полагается на другой метод – TestIncomingRouteResult(). Этот метод применяет рефлексию .NET, так что мы можем использовать анонимный тип для выражения любых дополнительных переменных сегментов. Не переживайте, если этот метод кажется бессмысленным – он предназначен только для удобства тестирования и для понимания MVC не обязателен.

Ниже приведен код метода TestIncomingRouteResult():

Нам также необходим метод для проверки, что URL не работает. Как вы увидите, это может быть важной частью определения схемы URL:

Методы TestRouteMatch() и TestRouteFail() содержат вызовы метода Assert(), которые генерируют исключение, если утверждение терпит неудачу. Поскольку исключения C# распространяются вверх по стеку вызовов, мы можем создать простые тестовые методы, которые будут проверять набор URL, и получить требуемое поведение тестирования.

Ниже приведен код тестового метода, проверяющего маршрут, который был определен ранее:

Этот тест использует метод TestRouteMatch() для проверки ожидаемого URL и также проверяет URL в том же самом формате, чтобы удостовериться в корректном получении значений controller и action с применением сегментов URL. Мы также с помощью метода TestRouteFail убеждаемся, что приложение не принимает URL, которые имеют неподходящее количество сегментов. Во время тестирования URL должен снабжаться префиксом в виде тильды (

) – именно так платформа ASP.NET представляет URL системе маршрутизации.

Обратите внимание, что мы не нуждаемся в определении маршрутов в тестовых методах. Причина в том, что мы загружаем их напрямую с помощью метода RegisterRoutes() в классе RouteConfig.

Комментировать
2 просмотров
Комментариев нет, будьте первым кто его оставит

Это интересно
Adblock detector