Как маршрутизировать древовидные URL-адреса с помощью маршрутизации ASP.NET?

Маршруты обрабатываются в порядке добавления в коллекцию. Вы можете добавить свой собственный маршрут после существующих маршрутов, чтобы убедиться, что он последний, у которого есть шанс обработать запрос. Это позволит вам добавлять маршруты для существующих файлов (виртуальных или иных) перед ним и, следовательно, соответствовать критериям 1 и 2.

По умолчанию маршрутизация MVC направляется к существующим файлам перед применением любых маршрутов, хранящихся в коллекции маршрутов; см. http://msdn.microsoft.com/en-us/library/system.web.routing.routecollection.routeexistingfiles.aspx. (шапка Павлу - см. комментарии).

Чтобы направить запросы к контроллеру страницы, просто создайте настраиваемый маршрут, который проверяет виртуальный путь, и, если он соответствует шаблону для страницы в базе данных, возвращает RouteData. Настройте свой RouteData с соответствующими значениями, извлеченными из виртуального пути (например, установите для ключа Path значение / Parent / Child / Grandchild), установите ключ контроллера на имя контроллера вашей страницы (например, Page) и действие на имя действия которые вы хотите выполнить (например, Показать). RouteData должен быть создан с MvcRouteHandler (не уверен, что это правильное имя класса).

Чтобы убедиться, что URL-адреса страниц, управляемых вашей базой данных, возвращаются правильно, переопределите метод GetVirtualPath( RequestContext, RouteValueDictionary ) для RouteBase и используйте переданные значения маршрута, чтобы определить, является ли это страница, управляемая базой данных, и создает ли она требуемые данные виртуального пути (или возвращает null, в противном случае ).

Чтобы получить помощь по переопределению GetRouteData и GetVirtualPath, посмотрите отраженный исходный код System.Web.Routing.RouteBase и System.Web.Routing.Route; после этого Google - ваш друг.

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

Еще одна идея - использовать T4 (набор инструментов преобразования текстовых шаблонов) для однократного чтения ваших дочерних элементов и генерации содержимого вашего файла Global.asax.

РЕДАКТИРОВАТЬ: в основном с T4 вы можете автоматизировать создание текстовых файлов. Например, вместо того, чтобы вручную копировать элементы какой-то огромной коллекции и вставлять их с определенным контекстом в текстовый файл (например, INSERT INTO [MyTable] (Text) VALUES (@ItemText)), вы могли бы заставить движок T4 читать коллекцию и генерировать эти операторы вставки для вас. Он статичен и не предназначен для выполнения.

Я считаю, что очень хорошее введение можно найти в книге Pro Entity Framework 4.0.

Но если вы говорите, что вам нужно делать это динамически, возможно, этот инструмент не для вас.

Вы знаете структуру своих страниц, когда сохраняете страницу. Итак, вы можете сгенерировать URL-адрес для каждой страницы и сохранить его в записи базы данных. Затем вы можете использовать правило {*path} и найти точное совпадение в базе данных. Это правило должно быть последним в вашем определении правил, чтобы вы могли сопоставить другие маршруты.

Например, у вашего Page1 нет родительской страницы, это URL Page1. Ваш SubPage знает, что это родитель, поэтому он может обрабатывать URL Page1/SubPage и т. Д.

Вы можете использовать шаблон "Page/{*path}". Затем вы можете либо разложить путь, разделив строку на «/» и пройти по нему, либо вы можете использовать предложение Раруша о сохранении [сгенерированного] пути в базе данных и выполнить прямой поиск.

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

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

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

Ваш путь будет выглядеть так:

http://mysite.com/Page/Page1/ 
http://mysite.com/Page/Page1/SubPage/ 
http://mysite.com/Page/Page/ChildPage/GrandChildPage/ 

Конечно, вы можете использовать префикс, отличный от «Страница».