Как отложить использование HttpHandler по умолчанию для ASP.NET MVC после обработки потенциального переопределения?

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

Просмотрев целую кучу примеров, блогов, статей и т. д. по реализации пользовательской маршрутизации для ASP.NET MVC, я так и не нашел варианта использования, подходящего для моего сценария. У нас есть существующая реализация для ASP.NET, которая работает нормально, но мы возвращаем «стандартный» обработчик, если переопределения не совпадают. Методика, которую мы сейчас используем, очень похожа на описанную в этой статье MSDN: http://msdn.microsoft.com/en-us/library/ms972974.aspx#urlrewriting_topic5, в котором говорится, что "фабрика обработчиков HTTP может возвращать обработчик HTTP, возвращенный классом System.Web.UI.PageParser". GetCompiledPageInstance(). (Это тот же метод, с помощью которого работает встроенная фабрика обработчиков HTTP веб-страниц ASP.NET, PageHandlerFactory.)".

Я пытаюсь понять: как я могу сначала просмотреть входящий запрос, а затем передать его в маршрутизацию MVC, если текущий запрос не соответствует ни одному из динамически настроенных (через таблицу данных) значений?


url-rewriting asp.net asp.net-mvc
person John Kaster    schedule 26.05.2009    source источник

Ответы (2)


arrow_upward
2
arrow_downward

Вам нужно будет:

  1. Не используйте стандартный метод расширения MapRoute в global.asax (это то, что настраивает обработчик маршрута).
  2. Вместо этого напишите свой собственный подтип маршрута, вот так.
person Craig Stuntz    schedule 26.05.2009
comment
Большое спасибо, Крейг. Я не нашел этот пост во всех поисках, которые я сделал. При обсуждении этого с моей командой было высказано мнение, что мы должны отдавать предпочтение НОВЫМ шаблонам URL-адресов для долгосрочной и лучшей производительности и оставить устаревшее перенаправление URL-адресов в качестве запасного варианта, где мы можем проверить соответствие шаблону, прежде чем возвращать 404 ошибка. Но блог, на который вы ссылаетесь, все еще может быть полезен для некоторых других сценариев, которые у нас есть. - person John Kaster; 26.05.2009

arrow_upward
1
arrow_downward

Хотя я объяснил Крейгу, что, возможно, мне больше не нужно переопределять сценарий (отдавая предпочтение будущему, а не прошлому), я понял, что есть простое и достаточно чистое место, где это переопределение может быть реализовано — в файле кода Default.aspx. Вот стандартный метод Page_Load:

    public void Page_Load(object sender, System.EventArgs e)
    {
        // Change the current path so that the Routing handler can correctly interpret
        // the request, then restore the original path so that the OutputCache module
        // can correctly process the response (if caching is enabled).

        string originalPath = Request.Path;
        HttpContext.Current.RewritePath(Request.ApplicationPath, false);
        IHttpHandler httpHandler = new MvcHttpHandler();
        httpHandler.ProcessRequest(HttpContext.Current);
        HttpContext.Current.RewritePath(originalPath, false);
    }

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

person John Kaster    schedule 26.05.2009
comment
Я не думаю, что это используется для всех запросов. См. комментарий в файле aspx. Однако вы можете переопределить Controller.HandleUnknownAction. - person Craig Stuntz; 27.05.2009