2010-12-14 14 views

Répondre

10

En fait, ils sont juste différents points de pipeline d'exécution MVC.

  1. ExecuteCore est appelé par MvcHandler après le contrôleur lui-même est instancié. À ce moment, MVC ne sait même pas comment le contrôleur va invoquer son action. Vous pouvez remplacer le ExecuteCore du contrôleur standard pour tordre son processus d'exécution global un peu .

  2. OnActionExecuting est une histoire totalement différente de . Il est appelé pendant l'appel des filtres d'action par ControllerActionInvoker. En ce moment-là MVC sait déjà que l'action existe, l'invoque, obtient tous les filtres (généralement définis comme attributs) et l'exécute dans un moment de pipeline d'exécution globale (OnActionExecuting, OnActionExecuted, OnResultExecuting et ainsi de suite).

Cela dépend de ce que vous voulez exactement réaliser lorsque vous décidez du point d'extension à utiliser.

  • Override ExecuteCore en dérivé Controller Tweak son comportement commun (pas vraiment souvent le cas en application normale).
  • Utilisez des filtres pour effectuer certaines tâches supplémentaires qui semblent orthogonale à ce que acion lui-même est censé faire (souvent cela est une logique AOP-like ou se rapporte à la session base de données/gestion des transactions).
5

ExecuteCore est appelée juste après l'initialisation du contrôleur tandis que OnActionExecuting se produit à un stade ultérieur du pipeline d'exécution et est appelée immédiatement avant que l'action du contrôleur ne soit appelée. Dans la deuxième méthode, vous pouvez manipuler directement le ActionResult et court-circuiter l'exécution de l'action en redirigeant par exemple à une autre action:

filterContext.Result = ... 
+2

Quels types de scénarios sont adaptés à chaque méthode? J'ai vu un exemple de localisation, il a utilisé ExecuteCore pour obtenir les paramètres de langue/culture. J'ai utilisé OnActionExecuting pour ajouter des viewdata communes que toutes les actions utilisent ... juste curieuses. Merci! – Chaddeus