2010-10-12 5 views
2

J'essaie de trouver la stratégie de gestion des exceptions idéale pour mon projet MVC. J'ai fait ce qui suit et je cherche des commentaires.MVC Controller.OnException pour différents types de résultats

Problème:

J'ai types de résultats disparates (Pages, Pages partielles, JSON, fichiers, etc.). Controller.OnException() n'a pas un moyen facile d'identifier quel type de résultat le client attend. Sans rien de spécial je sers une page HTML quand ils veulent JSON et ainsi de suite, ce qui conduit à afficher des problèmes.

Solution:

  1. J'ai une BaseController abstraite qui a des fonctions utilitaires comme HandleJsonException(), HandlePartialPageException(), HandlePageException(), etc. Ces fonctions:

    a) la main hors Enterprise Library pour l'enregistrement et les notifications .

    b) Définissez une vue de résultat dans le format attendu par le client.

    c) Définissez un code d'état Http approprié pour l'erreur. Je sépare mes actions en différents contrôleurs en fonction du type de résultat. Par exemple, au lieu de AbcController j'ai AbcPageController et AbcJsonController. Le OnException pour ce contrôleur appelle l'un des gestionnaires d'utilitaire de classe de base. JavaScript (pour les pages JSON et les pages partielles) examine le code d'état pour diriger le comportement dans certains cas.

Mon inquiétude est que la logique d'affichage dicte la conception des contrôleurs et donc influencer le routage (pas l'URL, mais les routes évidemment). En outre, cela encombre les stratégies d'héritage antérieures en ce qui concerne OnAuthenticate partagé sur les contrôleurs de base.

Quoi qu'il en soit ... Vous cherchez un avis. Et peut-être des liens vers les solutions d'autres personnes à ce problème.

Vive

Répondre

1

Controller.OnException() ne dispose pas d'un moyen facile d'identifier ce type de résultat que le client attend

Vous pouvez utiliser l'en-tête de demande Accept qui normes clients respectueux envoyer pour indiquer quels types de contenu ils supportent et attendent en retour. Par exemple, si vous utilisez la méthode jquery.getJSON(), l'en-tête suivant sera envoyé: Accept: application/json, text/javascript, */*. Comme vous pouvez le voir application/json est le format préféré ici et vous pouvez utiliser cette information dans votre contrôleur.

+0

Merci Darin. Cela semble prometteur et je peux aller dans cette direction. Cela fonctionne pour JSON mais pour text/html (ou */*) je ne peux pas distinguer entre un client qui veut une page HTML et un qui veut un fragment HTML PartialView. –

0

J'ai fini par abandonner cette approche.

Les erreurs traitées retourneront un résultat approprié directement à partir de l'action du contrôleur.

Erreurs non gérées traitées dans le contrôleur.OnException sera:.

a) mis la HttpStatusCode à 500. b) rendre une pleine page HTML avec nos applications page d'erreur c) définir la propriété traitée true si les pages d'erreur personnalisée ne se déclenche pas

Si l'appelant s'attend à autre chose qu'une page HTML (Ajax JSON, Page partielle, XML, etc.) examinera le code 500 et ignorera le contenu HTML.

Questions connexes