2014-12-23 4 views
2

У меня есть общедоступный actionresult, который я хотел бы использовать как своего рода предварительный процессор для работы перед передачей частному действию. Я планирую использовать первое действие контроллера для вызова внешнего API, который помещает запрашивающий IP-адрес в шкалу, измеряющую потенциальную мошенническую деятельность этого адреса. Возможные уровни, которые могут быть возвращены этим вызовом API: Low, Medium, High.private controller actionresult с outputcache

Общая идея о том, что я имею в виде выглядит следующим образом:

public async Task<ActionResult> RiskCheck(string id, int page) { 
    // Check risk for request with external API 
    var riskLevel = await SomeRiskCheckAsync(); 

    return PageOutput(id, page, riskLevel); 
} 

[OutputCache(Location = OutputCacheLocation.Server, Duration = Int32.MaxValue, VaryByParam = "id;page;riskLevel")] 
private async Task<ActionResult> PageOutput(string id, int page, string riskLevel) { 
    if (riskLevel.Equals("Low") { 
     return View("Low_Risk"); 
    } else if (riskLevel.Equals("Medium")) { 
     return View("Medium_Risk"); 
    } else { 
     return View("High_Risk"); 
    } 
} 

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

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

Во-вторых, мне кажется, что я мог бы объединить оба вида в один, если бы я смог использовать защитный код VaryByCustom на RiskCheck и использовать это настраиваемое переопределение для проверки риска раньше времени. Это на самом деле подход, который я пошел первым. Однако, когда я перешел на переопределение GetVaryByCustomString(HttpContext context, string custom), я понял, что нет асинхронной версии.

public override GetVaryByCustomString(HttpContext context, string custom) { 
    // Can't await this result 
    var riskLevel = await SomeRiskCheckAsync(); 
    return riskLevel; 
} 

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

ответ

1

Чтобы ответить на ваш первый вопрос:

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

Мое мнение по второму вопросу:

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

Смежные вопросы