ASP.NET MVC - какая самая ранняя точка в цикле запроса, где вы можете обнаружить статический запрос ресурса? - PullRequest
Новая
       38

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

1 голос
/ 26 июля 2011

Чтобы дать этому вопросу некоторый контекст, я написал профилировщик, который вызывается в Application_BeginRequest, но он регистрирует все (например, JavaScript, изображения и т. Д.).Хотя в качестве крайней меры можно было бы добавить фильтрацию к клиенту профилировщика, я бы предпочел активировать профилировщик только тогда, когда можно будет определить, что запрос требует маршрутизации.В идеале это было бы в Application_BeginRequest, но я не думаю, что это было бы возможно без избыточной обработки входящего запроса на маршрутизацию ...

Короче говоря, когда это самая ранняя точка в жизненном цикле запроса, которую яможет определить, является ли запрос статическим ресурсом или нет, и как бы вы поступили с ним?

Возможно ли получить из или перехватить в System.Web.Routing.RouteTable и вызвать мой код профилировщика изесть

Ответы [ 3 ]

2 голосов
/ 26 июля 2011

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

Например, я бы создал ProfilerAttribute для профилирования 

public class ProfilerAttribute : FilterAttribute, IActionFilter, IResultFilter, IExceptionFilter {
    public void OnActionExecuting(ActionExecutingContext filterContext) {
        Debug.WriteLine("Before Action is executing");
    }

    public void OnActionExecuted(ActionExecutedContext filterContext) {
        Debug.WriteLine("After Action is executed");
    }

    public void OnResultExecuted(ResultExecutedContext filterContext) {
        Debug.WriteLine("After Action Result is executed");            
    }

    public void OnResultExecuting(ResultExecutingContext filterContext) {
        Debug.WriteLine("Before Action Result is executing");
    }

    public void OnException(ExceptionContext filterContext) {
        Debug.WriteLine("oops! exception");
    }
}

и зарегистрировался бы как GlobalFilter в Global.ascx .... 

public static void RegisterGlobalFilters(GlobalFilterCollection filters) {
    filters.Add(new HandleErrorAttribute());
    filters.Add(new ProfilerAttribute());
}

Надеюсь, это поможет.Благодарю.

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

2 голосов
/ 26 июля 2011

Существуют различные варианты. Сначала - определить статический файл с помощью Request.PhysicalPath - проверить: Проверить наличие статического файла во время Application_BeginRequest?

Одной из альтернатив может быть использование этого в качестве обработчика и использование пути, чтобы отметить типы файлов для включения (* .aspx), например, в ваш web.config. Тогда вы сможете получить доступ к событиям довольно рано (см. Конвейер asp.net)

Или просто используйте httpmodule - проверьте все и профилируйте нефизические элементы, как вы упомянули.

Или - используйте ваш текущий метод с первой ссылкой, чтобы просто проверить Request.PhysicalPath и надеяться, что он работает для вас:)

1 голос
/ 26 июля 2011

Я пытался подойти к нему под другим углом, и я намного доволен результатом.По сути - зачем выявлять статические запросы ресурсов, когда вы просто не можете «направить» их вообще?В global.asax: 

private readonly string[] STATIC_CONTENT_PATHS = new string[] { "css", "js", "img" }; 

public static void RegisterRoutes(RouteCollection routes)
{    
    foreach (string path in STATIC_CONTENT_PATHS) { routes.IgnoreRoute(path + @"/{*foo}"); }

    // other MapRoute calls here
}

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

protected void Application_BeginRequest()
{            
    if (IsStaticRequest())
    {
         // do something here
    }
}

private bool IsStaticRequest()
{
   var result = Request.Url.AbsolutePath.Split('/');
   if (result.Length < 2) return false;
   return STATIC_CONTENT_PATHS.Contains(result[1]);
}

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

...