Текст книги "Asp.net mvc framework"
Автор книги: Гайдар Магдануров
сообщить о нарушении
Текущая страница: 11 (всего у книги 17 страниц)
Создание маршрутов
В предыдущей части этой главы мы уже рассмотрели простой пример создания маршрута и класс Route, который используется для этих целей. При создании маршрута с помощью класса Route важную роль играют параметры имени маршрута, Url и три словаря параметров, определенные свойствами Defaults, Constraints и DataTokens. Рассмотрим их назначение и применение более подробно.
Наименование маршрута
В MVC Framework добавление маршрута реализуется путем вызова одного из вариантов MapRoute, методов расширения RouteCollection. Одним из отличиев MapRoute является требование к обязательному указанию имени маршрута, тогда как стандартные средства RouteCollection позволяют добавить маршрут без указания имени.
Примечание
Следует учесть, что имена для маршрутов должны быть уникальными. При попытке добавить в таблицу маршрутизации маршрут с именем, которое уже существует в таблице, будет вызвано исключение.
********************************
Имя маршрута – это достаточно важная часть маршрутизации в MVC Framework. Есть несколько полезных вариантов использования имени маршрута, рассмотрим их по порядку.
RedirectToRoute
Имя маршрута используется для возврата результата действия в виде RedirectToRouteResult с помощью стандартного метода контроллера RedirectToRoute. Назначение RedirectToRoute – это перенаправление выполнения запроса с одного маршрута на другой. На самом деле, для переадресации на другой маршрут MVC Framework на основании переданного имени маршрута генерирует строку URL, которая соответствует новому маршруту и производит возврат клиенту ответа в виде требования на переадресацию на новый URL (redirect).
К примеру, допустим определен маршрут с именем AccountLogOn так, как показано далее:
routes.MapRoute(
"AccountLogOn",
"Account/LogOn",
new { controller = "Account", action = "LogOn" }
);
В этом случае вызов RedirectToRoute, который переадресует пользователя на новый маршрут, будет выглядeть так:
public ActionResult SomeAction()
{
return RedirectToRoute("AccountLogOn");
}
После выполнения действия SomeAction пользователь будет перенаправлен на URL Account/LogOn, согласно определению маршрута AccountLogOn.
AjaxHelper
В методах расширения класса AjaxHelper, таких как BeginRouteForm и RouteLink, имя маршрута используется для генерации строки запроса.
BeginRouteForm – это метод расширения, который позволяет упростить создание формы для отправки результатов через Ajax.BeginRouteForm в данном смысле является аналогом BeginForm другого метода расширения класса AjaxHelper, который строит форму на основании определенных значений контроллера и действия. В случае, когда вызывается BeginRouteForm, механизм класса AjaxHelper формирует на базе имени маршрута строку URL и подставляет ее атрибуту action при рендеринге формы в представлении.
RouteLink – это метод расширения, позволяющий упростить создание ссылки в представлении, которая осуществляла бы Ajax-запросы. Роль имени маршрута при работе RouteLink точно такая же, как и в BeginRouteForm – по имени маршрута строится URL-строка, которая рендерится в представлении в виде атрибута href.
UrlHelper
В методе расширения RouteUrl класса UrlHelper имя маршрута используется для создания строки URL, соответствующей маршруту.
Шаблон маршрута и свойство Url
При создании маршрута строковый параметр Url определяет шаблон маршрута, который, как правило, задает некоторую группу возможных клиентских запросов. Следует учитывать, что при наличии нескольких маршрутов механизм маршрутизации ASP.NET всегда выбирает самый первый из них – тот, что был добавлен в таблицу маршрутизации первым.
Как мы уже говорили, по умолчанию MVC Framework создает один-единственный маршрут с именем Default и шаблоном {controller}/{action}/{id}. Этот маршрут хорош тем, что он один позволяет обрабатывать большую часть возможных пользовательских запросов. По сути такой шаблон говорит о том, что данный маршрут определяет все запросы с вложениями до третьего уровня, т. е. этот маршрут обработает и http://sample.domain/level1/ и http://sample.domain/level1/level2/, и http://sample.domain/level1/level2/level3/, где level1, level2 и level3 могут принимать любые значения. На самом деле это очень большое количество возможных запросов и на практике один маршрут Default покрывает все требования разработчиков к маршрутизации.
Однако разработчик может добавить гибкости своему проекту и улучшить представления строк URL, если определит свои маршруты. Далее представлено два подобных маршрута:
routes.MapRoute(
"AccountLogOn",
"LogOn",
new { controller = "Account", action = "LogOn" }
);
routes.MapRoute(
"Home",
"{action}",
new { controller = "Home", action = "Index" }
);
Первый вызов MapRoute создает маршрут под наименованием AccountLogOn, шаблон которого четко соответствует только одному возможному клиентскому запросу http://sample.domain/Logon. Второй вызов создает маршрут Home более широкого определения. Под этот маршрут попадают все клиентские запросы вида http://sample.domain/Home/{action}.
Польза от создания таких маршрутов очевидна. Имея набор именованных маршрутов, которые четко определяют область клиентских запросов, а не обхватывают все запросы подряд, вы можете более гибко управлять маршрутами. Например, теперь для простого перенаправления на страницу входа в систему вам достаточно будет вызвать следующий метод:
public ActionResult SomeAction()
{
return RedirectToRoute("AccountLogOn");
}
Другим видимым преимуществом этого маршрута является то, что согласно ему клиентский запрос не обязательно должен содержать в себе наименование контроллера. Таким образом, путь http://some.domain/Account/LogOn уменьшается до http://some.domain/LogOn, что придает ссылкам вебприложения более компактный вид. Компактность строк запросов может играть свою роль в случае, когда в большом веб-приложении используются десятки контроллеров с массой действий и параметров.
Значения параметров маршрута по умолчанию и свойство Defaults
Свойство Defaults определяет набор параметров, сопоставляемых параметрам маршрута по умолчанию, в случае, когда URL строки запроса их не содержит. Рассмотрим для примера маршрут {controller}/{action}/{id}, создаваемый в проектах MVC Framework по умолчанию. При его создании свойство Defaults было инициализировано с помощью метода расширения MapRoute следующим значением:
new { controller = «Home», action = «Index», id = "" }
На практике это будет означать, что механизм MVC Framework одинаково обработает запросы http://sample.domain/Home/Index/, http://sample.domain/Home/ и http://sample.domain/. Все эти запросы приведут к вызову действия Index в контроллере HomeController. Это стало возможным, поскольку были определены значения по умолчанию для параметров маршрута controller и action. В связи с этим URL http://sample.domain/ при сопоставлении маршруту дополучит часть параметров из словаря Defaults, став, таким образом, равнозначным запросу http://sample.domain/Home/Index/.
Ограничения параметров маршрута и свойство Constraints
Свойство Constraints определяет набор параметров, которые служат ограничителями для параметров маршрута. Рассмотрим пример: при создании проекта вы определяете маршрут, один из параметров которого указывает логин пользователя. Согласно правилам вашего ресурса логин пользователя не может содержать менее 4 символов в виде букв и цифр. Поэтому все запросы, которые попадают под ваш маршрут и содержат параметр логина пользователя с тремя или менее символами либо с недопустимыми символами, вы рассматриваете как ошибочно сформированные. Задача по обработке такой ситуации идеально вписывается в механизм ограничений маршрутов, который представлен свойством Constraints.
Чтобы решить задачу с ограничением на длину имени логина в запросе, нужно определить следующее ограничение в свойстве Constraints при создании маршрута:
var constraint = new RouteValueDictionary {
{"user", "\w{4,}"}
};
routes.Add(new Route(
"{controller}/{action}/{user}/",
defaults,
constraint,
null,
new MvcRouteHandler()
));
Ограничение определяется как элемент словаря RouteValueDictionary, где ключом является имя параметра, а значением регулярное выражение, описывающее правило для параметра. В данном случае регулярное выражение w{4,} предполагает, что строка должна содержать буквы и цифры в размере от 4 элементов.
После такого определения маршрута, если вы попытаетесь обратиться по следующему адресу http://sample.domain/Home/Index/foo, вы получите стандартное сообщение браузера о возвращенной сервером ошибке с кодом 404 «Страница не найдена».
Ранее в этой главе мы рассмотрели ограничения параметров как коллекцию регулярных выражений в свойстве Constraints класса Route. Однако существует еще один, альтернативный, способ создания маршрута на базе интерфейса iRouteConstraint. Он также описан в этой главе. Вместо того чтобы добавлять в коллекцию Constraints строки с регулярными выражениями, можно воспользоваться интерфейсом IRouteConstraint и реализовать класс, который будет выполнять проверку параметров на соответствие условиям. Добавляется такой класс похожим на обычный способом:
routes.MapRoute(«Default»,
"{controller}/{action}/{user}",
new {controller = "Home",
action = "Index",
id = ""},
new {user = new SampleConstraint()}
);
Здесь SampleConstraint – это класс, который реализует интерфейс IRouteConstraint.
Параметры маршрута и свойство DataTokens
В механизме маршрутизации ASP.NET при создании маршрута можно указать набор параметров DataTokens. Используя DataTokens, разработчик может передать в маршрут набор данных, которые позднее будут использованы пользовательским вариантом обработчика маршрута при сопоставлении клиентского запроса маршруту. Иными словами, DataTokens помогает определить больше данных для маршрутов в случае, когда пользователь сам определяет обработчик маршрута. В MVC Framework каждому маршруту сопоставляется уже готовый обработчик MvcHandler. Поэтому надобность в пользовательских параметрах, передаваемых через DataTokens, отпадает, очевидно, что эти данные MvcHandler использовать не сможет. В связи с тем, что данные DataTokens в проектах MVC Framework по умолчанию не нужны, в методе расширения MapRoute создание такого набора вовсе отсутствует.
Однако есть исключение, делающее свойство DataTokens экземпляра маршрута полезным даже для проектов MVC Framework. Дело в том, что фабрика контроллеров по умолчанию проверяет DataTokens на наличие параметра Namespaces, от которого в дальнейшем зависит, какие контроллеры могут быть выбраны для инстанцирования.
Параметр Namespaces может содержать строки в виде перечисления типа iEnumerable
Наличие такого механизма, как ограничение поиска контроллеров для маршрута определенным списком пространств имен, нельзя переоценить. В крупных проектах, в которых могут создаваться десятки или сотни пространств имен, поиск типа контроллера через механизм отражений может занимать неоправданно много процессорного времени. Ограничив маршрут набором пространств имен, вы поможете фабрике контроллеров более быстро найти и инстанцировать необходимый для обработки маршрута контроллер.
Для того чтобы указать определенный набор пространств имен при создании маршрута, необходимо проделать примерно такие действия:
var route = routes.MapRoute(
"AccountLogOn",
"LogOn",
new { controller = "Account", action = "LogOn" }
);
route.DataTokens = new RouteValueDictionary();
List
nsList.Add("SomeNamespace");
nsList.Add("SomeNamespace2");
route.DataTokens.Add("Namespaces", nsList);
Здесь после создания собственно маршрута, у него инициализируется свойство DataTokens и заполняется ключом Namespaces со значением списка из двух строк с именами пространств имен SomeNamespace и SomeNamespace2. Такие действия с маршрутом подразумевают, что контроллер для него будет искаться в пространствах имен SomeNamespace и SomeNamespace2.
Еще одна возможность ограничить список пространств имен, в которых фабрика контроллеров ищет контроллеры для инстанцирования, – это свойство DefaultNamespaces класса ControllerBuilder. В каждом приложении MVC Framework существует экземпляр ControllerBuilder в виде статического свойства Current класса ControllerBuilder. Используя свойство DefaultNamespaces, вы можете определить пространства имен по умолчанию, в которых фабрика контроллеров будет искать контроллеры.
ControllerBuilder.Current.DefaultNamespaces.Add(«SomeNamespaces3»);
DataTokens и DefaultNamespaces можно использовать вместе. В целом очередность работы механизмов DataTokens и DefaultNamespaces в процессе поиска контроллера следующая:
1. Фабрика контроллеров пытается найти контроллер в пространствах имен, определенных в DataTokens маршрута, поиск прекращается, если такой контроллер найден.
2. Фабрика контроллеров пытается найти контроллер в пространствах имен, определенных через DefaultNamespaces, поиск прекращается, если контроллер найден.
3. В конце концов, фабрика контроллеров просматривает все пространства имен в поиске необходимого контроллера.
Здесь следует обратить внимание на то, что определение неверных пространств имен в DataTokens и DefaultNamespaces может привести к тому, что поиск вместо ускорения замедлится, поскольку будет проходить трижды, согласно информации каждого механизма.
Игнорирование маршрутов
Игнорирование маршрутов – это необходимый инструмент, позволяющий указать маршрут, т. е. группу клиентских запросов, которые не будут обрабатываться MVC Framework. Есть множество случаев, когда запрос не должен обрабатываться как запрос к MVC Framework. Например, запросы к изображениям, находящимся на сервере, или к любым другим статическим ресурсам, таким как файлы скриптов или стилей. Нет совершенно никакой необходимости в том, чтобы такие запросы проходили через многоступенчатую обработку MVC Framework. Вместо этого файлы изображений или стилей должны отдаваться клиентам напрямую.
По умолчанию механизмы маршрутизации ASP.NET, а следовательно, и MVC Framework исключают запросы к существующим локальным файлам из обработки механизмом маршрутизации. Но, как будет показано далее, существует возможность гибко управлять тем, какие файлы пропускать, а какие – нет.
Чтобы создать правило игнорирования маршрута, MVC Framework содержит IgnoreRoute – метод расширения класса RouteCollection. Этот метод имеет следующие входные параметры:
□ url – указывает шаблон маршрута, все запросы, которые подпадают под этот маршрут, будут игнорироваться MVC Framework;
□ constraints – указывает дополнительный набор параметров, позволяющий более гибко задать условия, при которых производится игнорирование.
Когда создается проект MVC Framework через шаблон в Visual Studio, то в файле global.asax автоматически будет сгенерировано определение одного маршрута игнорирования:
routes.IgnoreRoute(«{resource}.axd/{*pathInfo}»);
Это определение маршрута игнорирования достаточно просто демонстрирует, зачем вообще нужно игнорировать маршруты. Определение этого правила необходимо потому, что AXD-файлов на самом деле не существует, и запросы вида some.domain/resource.axd обрабатываются отдельным обработчиком. А так как механизмом MVC Framework игнорируются запросы только к существующим файлам, то определяется, что все запросы к AXD-ресурсам должны обрабатываться не механизмом MVC Framework, но другим обработчиком, который в данном случае определен в web.config как System.Web.Handlers.ScriptResourceHandler.
Рассмотрим простейший пример создания маршрута для игнорирования. Для этого разберем следующую ситуацию: как известно, каждый браузер при переходе на любой сайт старается найти в корне этого сайта специальную иконку, которая сопоставлена с сайтом. Эта иконка обычно представляет собой файл с названием favicon.ico и используется браузером для отображения в своем интерфейсе, например в списке избранного, если сайт туда добавлен.
Когда вы не определяете такие иконки на своем сайте либо определяете их через разметку страницы, тогда запрос к отсутствующему файлу приведет к тому, что будет вызван механизм MVC Framework. Для того чтобы такие запросы клиентских браузеров не вызывали работу механизма MVC Framework, нам следует добавить следующее правило игнорирования маршрута:
routes.IgnoreRoute(«favicon.ico»);
Этим определением мы указываем, что запрос вида http://some.domain/favicon.ico должен игнорироваться. Для более сложного варианта определим игнорирование маршрута к файлу favicon.ico для всех папок нашего сайта, а не только к корневой папке:
routes.IgnoreRoute(«{*param}»,
new { param = @"(.*/)?favicon.ico(/.*)?" });
Здесь мы уже используем два параметра, первый со значением {*param} определяет шаблон маршрута, в данном случае его можно описать как все пути, которые завершаются со значением параметра шаблона param. Второй параметр new{param=@" (.*/) ?favicon.ico (/.*)?"} задает определение параметра шаблона param в виде регулярного выражения, т. е. определяет, на что должна заканчиваться строка URL в клиентском запросе для того, чтобы маршрут игнорирования сработал.
Рассмотренные примеры работали в режиме, когда MVC Framework и механизм маршрутизации ASP.NET игнорируют запросы к существующим файлам. Однако имеет смысл перестать игнорировать такие запросы и самому обрабатывать запросы к группе определенных файлов, разрешая к ним доступ или запрещая его. Для того чтобы регулировать поведение маршрутизации ASP.NET в плане игнорирования запросов к существующим файлам, у класса RouteCollection, определяющего коллекцию маршрутов, есть булево свойство RouteExistingFiles. По умолчанию значение RouteExistingFiles установлено в false. Установив его в значение true, вы заставите механизм маршрутизации ASP.NET обрабатывать все запросы, в том числе и те, которые ведут на существующие файлы.
routes.RouteExistingFiles = true;
После этого любой запрос на локальный файл приведет к возникновению исключения и возврату клиенту информации об ошибке 404 «Страница не найдена». Теперь вы можете быть уверены в том, что пользователь не получит доступа ни к одному отдельному файлу на вашем сайте. Зато, определив правила игнорирования, для групп таких файлов вы сможете открыть доступ.
Рассмотрим пример использования игнорирования маршрутов для открытия доступа. Предположим, что в вашем проекте все стили, используемые на веб-страницах, расположены в папке some.domain/styles, а скрипты в some.domain/scripts. Теперь, чтобы открыть к ним доступ при включенном механизме маршуртизации для имеющихся файлов, достаточно определить следующие маршруты игнорирования:
routes.IgnoreRoute(«styles/{*pathInfo}»);
routes.IgnoreRoute("scripts/{*pathInfo}");
И в заключение рассмотрим последний простой пример, который часто используется на практике. Зачастую структура вашего проекта может содержать файлы с самыми разнообразными расширениями, которые вы отдаете пользователю по его запросу. Скажем, это может быть статический файл помощи с HTML-разметкой или текстовый файл с расширением txt, который может содержать информацию о лицензии. Механизм игнорирования маршрутов позволяет легко предоставить доступ к таким файлам даже при включенном механизме маршрутизации для имеющихся файлов. Например, следующий фрагмент кода разрешает загружать HTML– и TXT-файлы из корня сайта:
routes.IgnoreRoute(«{file}.txt»);
routes.IgnoreRoute("{file}.htm");
routes.IgnoreRoute("{file}.html");
Игнорирование маршрутов – это сильный инструмент, который по умолчанию позволяет создать правила для исключения из обработки запросов к виртуальным или несуществующим файлам. А после изменения RouteExistingFiles и включения механизма маршрутизации для всех запросов игнорирование маршрутов позволяет защитить все файлы от доступа и сформировать свои правила доступа к файлам на сайте.
Советы по использованию маршрутов
В этой главе мы рассмотрели механизм маршрутизации ASP.NET, используемые в нем классы, интерфейсы, свойства и коллекции. Мы показали, зачем нужен тот или иной параметр и для чего нужны коллекции параметров типа DataTokens или Constraints. В заключение главы мы расскажем о некоторых полезных советах по использованию механизма маршрутизации на практике.
Маршруты и валидация запросов
Как уже говорилось в этой главе, маршрутизация ASP.NET содержит механизм ограничений, который позволяет более гибко управлять обработкой маршрутов. Но кроме собственно поиска правильного маршрута, этот механизм позволяет также производить валидацию запросов еще на этапе поиска и обработки маршрута.
Представьте себе ситуацию, когда вы создаете маршрут, одним из параметров которого является число, определяющее год. Совершенно очевидно, что такое число имеет допустимые рамки, и его валидность может быть проверена еще на этапе сопоставления маршрутов. В листинге 6.1 приведен фрагмент кода, который определяет экземпляр класса, реализующий IRouteConstraint для такого рода проверки параметра.
Листинг 6.1. Класс, реализующий IRouteConstraint
public class YearConstraint : IRouteConstraint {
public bool Match(HttpContextBase httpContext,
Route route,
string parameterName,
RouteValueDictionary values,
RouteDirection routeDirection)
{
if (parameterName == "year")
{
try
{
object yearValue = values["year"];
int year = Convert.ToInt32(yearValue);
if (year >= 1900 && year <= 2100) return true;
}
catch
{
return false;
}
}
return false;
}
}
Для того чтобы использовать данный класс, необходимо определить маршрут с параметрами ограничения примерно так, как показано во фрагменте:
var constraints = new RouteValueDictionary
{
{"year", new YearConstraint()}
};
routes.MapRoute(«YearData»,
"{controller}/{action}/{year}",
new { controller = "Data", action = "Index" },
new { year = new YearConstraint() }
);
Вся прелесть этого механизма заключается в том, что вы можете использовать ограничение для параметров различных маршрутов. Таким образом, вы получаете централизованный механизм обработки и валидации входных параметров, который начинает работать еще до того, как в действие вступит контроллер.
Хранение маршрутов в базе данных
Порой определение маршрутов в файле global.asax – это недостаточно гибкий механизм для решения задачи, встающей перед разработчиком. Допустим, стоит задача передать права на создание, редактирование и удаление маршрутов некоему администратору. В таком случае предоставление доступа на редактирование файла global.asax может нарушить безопасность системы. В подобных ситуациях и когда необходимо выделить механизм доступа к созданию и редактированию маршрутов, обычно создается отдельное хранилище для данных маршрутов, которое используется для инициализации механизма маршрутизации при старте приложения.
Таким хранилищем может быть любой источник данных: от текстовых файлов и XML до отдельной базы данных, в таблицах которой хранятся определения маршрутов. Рассмотрим создание такой базы данных для хранения простейших маршрутов.
Для начала определим две таблицы, Routeitem и Param, для хранения данных о маршрутах так, как продемонстрировано на рис. 6.1 и 6.2.
Таблица Routeitem будет содержать информацию о маршрутах, а Param – соответственно, о параметрах для каждого маршрута.
Чтобы добавить в проект поддержку этих таблиц, создадим с помощью мастера Linq To Sql классы для работы. Получившийся DBML-файл будет представлять схему, показанную на рис. 6.3.
После создания классов Linq To Sql настало время создать логику по регистрации маршрутов в механизме маршрутизации. Для этого создадим класс DatabaseRoutes, представленный в листинге 6.2.
Листинг 6.2. Класс DatabaseRoutes
using System.Linq;
using System.Web.Mvc;
using System.Web.Routing;
namespace Routing {
public class DatabaseRoutes
{
readonly RouteDbDataContext db = new RouteDbDataContext();
private readonly RouteCollection Routes;
public DatabaseRoutes(RouteCollection routes)
{
Routes = routes;
}
public void Register()
{
var routes = db.RouteItems.Where(x => x.State).OrderBy(x => x.LoadOrder);
foreach (var route in routes)
{
RouteValueDictionary defaults = new RouteValueDictionary();
foreach (var param in route.Params)
defaults.Add(param.ParamKey, param.ParamValue);
Routes.Add(route.Name, new Route(
route.Template,
defaults,
new MvcRouteHandler()
));
}
}
}
}
Обратите внимание, конструктор-класс DatabaseRoute принимает параметр типа RouteColection, для того чтобы произвести регистрацию маршрутов. Единственный метод класса Register предназначен для выборки данных из базы данных и инициализации механизма маршрутизации в виде полученного экземпляра RouteColection.
Для того чтобы использовать наш класс, необходимо заполнить таблицы значениями. Сделаем это для определения стандартного маршрута Default так, как представлено на рис. 6.4 и 6.5.
После того как данные внесены в базу данных, можно интегрировать механизм в проект. Для этого следует в global.asax удалить старое определение маршрута Default и добавить инициализацию класса DatabaseRotes так, как показано в следующем фрагменте кода:
public static void RegisterRoutes(RouteCollection routes)
{
routes.IgnoreRoute("{resource}.axd/{*pathInfo}");
DatabaseRoutes dbRoutes = new DatabaseRoutes(routes);
dbRoutes.Register();
}
Если вы сделали все правильно, то результатом будет работа вашего проекта на основе маршрута, полученного из базы данных. Теперь, реализовав каким-либо образом доступ к базе данных маршрутов, вы получите возможность предоставить функции редактирования маршрутов администратору без модификации исходных кодов в виде global.asax.
Представленный пример предполагает реализацию хранения только простейших маршрутов. Для хранения данных об ограничениях, данных DataTokens или данных игнорирования маршрутов механизм придется расширить, что не должно составить труда.
Маршрутизация и тестирование
Когда дело касается модульного тестирования механизмов маршрутизации, то определение области тестирования не выглядит очевидным. Что необходимо тестировать? В простейшем случае, когда ваш проект на MVC Framework содержит всего один маршрут Default, определенный по умолчанию, модульное тестирование теряет большую часть смысла. Но в случаях, когда маршрутов в проекте много, повсеместно используется ограничение и игнорирование маршрутов, модульное тестирование обретает широкую область для применения.
Здесь мы на нескольких примерах рассмотрим, как включить в свой проект тесты маршрутов, ограничений и маршрутов игнорирования.
Тестирование определенных разработчиком маршрутов – достаточно простое, но важное дело. Так как маршрутизация – это один из краеугольных механизмов, который осуществляет работу веб-приложения, правильно функционирующие маршруты – важнейшая часть любой системы. Ошибка при переопределении маршрута или добавлении нового маршрута может стоить выхода из строя как отдельного функционала, так и всего сайта.
Для тестирования маршрутов воспользуемся тремя популярными средствами:
□ NUnit (http://www.nunit.org/index.php) – альтернативное средство тестирования;
□ RhinoMocks (http://ayende.com/projects/rhino-mocks.aspx) – позволяет создавать фальшивые, так называемые, «мок-объекты»;
□ MvcContrib (http://www.codeplex.com/MVCContrib) – содержит функционал, расширяющий возможности MVC Framework, в том числе и в сфере модульного тестирования.
Подготовка инструментов
Для того чтобы использовать инструменты тестирования в своем проекте, необходимо проделать следующие действия. Во-первых, установите пакет тестирования NUnit. Во-вторых, добавьте в проект ссылки на сборки:
MvcContrib.TestHelper.nunit.framework и Rhino.Mocks так, как показано на рис. 6.6.
После этих двух шагов вы готовы для создания модульных тестов механизма маршрутизации. Для тестирования в MvcContrib существует набор специальных методов расширения, которые позволяют значительно упростить создание тестов. Это метод ShouldMapTo
Создание тестов
Для демонстрации создания модульных тестов первым делом определим набор маршрутов, которые будут подвергнуты тестам. Далее представлен фрагмент кода с определением ряда маршрутов:
routes.IgnoreRoute(«{resource}.axd/{*pathInfo}»);
routes.MapRoute(
"Product",
"Product/{id}",
new { controller = "Product", action = "GetById" }
);
routes.MapRoute(«ProductList»,
"ProductList/{year}",
new { controller = "Product", action = "List" },
new { year = new YearConstraint() }
);
routes.MapRoute(
"Default",
"{controller}/{action}/{id}",
new { controller = "Home", action = "Index", id = "" }
);
Как вы можете видеть, в коде определяется три маршрута: Product, ProductList и маршрут по умолчанию Default. Кроме того, определено стандартное правило игнорирования маршрута для игнорирования запросов к
AXD-ресурсам. Обратите внимание, что маршрут с названием ProductList содержит ограничение для параметра year (ранее в этой главе мы рассматривали это ограничение).
Для определения тестов необходимо создать простой класс, например, представленный во фрагменте:
namespace Routing {
using System.Web.Routing;
using MvcContrib.TestHelper;
using NUnit.Framework;
using Routing.Controllers;
[TestFixture]
public class TestRoutes
{
}
}
Обратите внимание на использование атрибута TestFixture. Это атрибут инструмента NUnit, который позволяет определить класс с набором тестов. Добавим в класс простой тест:
[Test]
public void TestSimpleRoute()
{
"~/".Route().ShouldMapTo
