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<T>, который позволяет протестировать строку определения маршрута, и метод ShouldBeIgnored, который позволяет протестировать правило игнорирования маршрута.
