Archives

Archives / 2008 / August
  • Sortie d’ASP.NET MVC Preview 4 (Partie 1)

    L’équipe d’ASP.NET MVC est actuellement à finaliser la sortie d’une nouvelle "Preview 4" qu’ils espèrent livrée un peu plus tard cette semaine.  La sortie de la Preview 3 avait comme objectif de finaliser plusieurs en grande partie les API core et plusieurs points d’extensibilité dans ASP.NET MVC. Avec la Preview 4 cette semaine vous commencerez à voir de plus en plus de fonctionnalité de haut niveau faire leur apparition qui vienne s’appuyer sur les fondations core et ajoute de la productivité.

    Il y à beaucoup de nouvelles fonctionnalités et possibilité dans ce nouveau build, tellement que j’ai décidé que j’allais avoir besoin de 2 post pour toutes les couvrir. La première partie couvrira les nouvelles fonctions de Caching, Gestion d’erreurs et de sécurité dans la Preview 4 ainsi les améliorations au niveau du testage qu’elle apporte. Mon prochain post couvrira les nouvelles fonctionnalités AJAX qui sont aussi ajoutées à cette sortie.

     

    Comprendre les intercepteurs de filtres

    Les attributs Action Filter sont une capacité d’extensibilité pratique d’ASP.NET MVC qui fût introduite lors de la sortie de la "Preview 2". Ceux-ci vous permettent d’injecter des intercepteurs de code dans la requête d’un contrôleur MVC qui peut être exécuté avant et après qu’un contrôleur ou c’est méthodes Action s’exécutent.  Ceci permet de développer d’excellents scénarios d’encapsulation où vous pouvez facilement emballer et réutiliser des fonctionnalités d’une manière propre et déclarative.

    Ci-dessous, un exemple d’un filtre hypersimple « ScottGuLog » que je pourrais utiliser pour logger les détails concernant une exception survenue durant l’exécution d’une requête. Implémenter une classe filtre personnaliser est très facile, il suffi d’hériter de la classe "ActionFilterAttribute" et de faire un override  des méthodes appropriées et exécuter le code avant et après qu’une méthode action soit invoqué sur le contrôleur et/ou avant ou après qu’un ActionResult soit converti en response.

    http://www.scottgu.com/blogposts/mvcpreview4/step1.png

    Utiliser un filtre dans un contrôleur ASP.NET MVC est facile, il suffit de le déclarer comme attribut d’une méthode action ou encore sur la classe contrôleur elle même (dans un tel cas ce sera appliqué sur toutes les méthodes action incluse dans le contrôleur):

    http://www.scottgu.com/blogposts/mvcpreview4/step2.png

    Ci-haut vous pouvez voir un exemple de deux filtres qui sont appliqués. J’ai mentionné que je voulais que mon "ScottGuLog" soit appliqué sur la méthode action "About", et que je voulais que le filtre “HandleError"  soit appliqué sur toutes les méthodes action de HomeController.

    Les versions précédentes des preview d’ASP.NET MVC permettent cette extensibilité des filtres, mais ne fussent pas livrées avec des filtres préconçus. La Preview 4 d’ASP.NET MVC comprend maintenant plusieurs filtres pratiques pour gérer l’output caching, la gestion d’erreur et les différents scénarios de sécurité.

     

    Filtre OutputCache

    Le filtre [OutputCache] offre une façon facile d’intégrer ASP.NET MVC avec les fonctions d’output caching d’ASP.NET (avec ASP.NET MVC Preview 3 vous deviez écrire du code arrivé à cela). 

    Pour tester ceci, modifiez la valeur « Message » au sein de la méthode action « index » du HomeController (conçut avec le template de projet VS ASP.NET MVC) pour afficher l’heure actuelle :

    http://www.scottgu.com/blogposts/mvcpreview4/step3.png

    Lorsque vous exécutez votre application, vous allez voir l’empreinte de temps se mettre à jour à chaque rafraichissement de la page :

    http://www.scottgu.com/blogposts/mvcpreview4/step4.png

    Nous pouvons activer l’output caching pour cette URL en y ajoutant l’attribut [OutputCache] à notre méthode action. Nous le configurerons pour qu’il conserve en cache les réponses pour une durée de 10 secondes avec la déclaration ci-bas :

    http://www.scottgu.com/blogposts/mvcpreview4/step5.png

    Maintenant, lorsque vous appuyé sur rafraîchir, vous aller voir que l’empreinte de temps ce mets à jour seulement au 10 secondes. Ceci est dû au fait que la méthode action est appelé seulement à chaque 10 secondes, toutes les autres requêtes entre cet intervalle sont servies à partir de l’output cache d’ASP.NET(ce qui veut dire qu’aucun code n’est exécuté donc c’est très rapide).

    En plus de supporter les durées en temps, l’attribut OutputCache supporte les mêmes options que l’output cache d’ASP.NET (vary by params, headers, content encoding, et custom logic). Par exemple, l’exemple ci-dessous sauvegarderait des versions différentes en cache de la page selon la valeur optionnelle du paramètre de QueryString "PageIndex", et automatiquement effectuer le rendu de la bonne version selon la valeur de la querystring de l’URL d’arrivé:

    http://www.scottgu.com/blogposts/mvcpreview4/step6.png

    Vous pouvez aussi intégrer avec la fonction d’invalidation de la cache de base de données d’ASP.NET qui vous permet d’automatiquement invalider la cache lorsqu’une base de données don’t dépend l’URL est modifié (truc: la meilleure façon d’implanter cela c’est de configurer la section CacheProfile de votre web.config et de le faire pointer vers l’attribut OutputCache).

     

    Filtre HandleError

    Le filtre [HandleError] offre un moyen d’indiquer de façon déclarative à un contrôleur ou à une méthode action qu’un message d’erreur amical devrait être affiché si une erreur survient lors de l’exécution d’une requête ASP.NET MVC. 

    Pour faire l’essai de ceci, ajoutez un nouveau "TestController" à un projet et implémenté une méthode action qui cause une exception comme ci-bas:

    http://www.scottgu.com/blogposts/mvcpreview4/step7.png

    Par défaut, lorsque vous pointez votre navigateur à cette URL, la page d’erreur ASP.NET par défaut pour les usagers distants sera affichée (à moins d’avoir configuré au préalable la section <customErrors> dans le web.config):

    http://www.scottgu.com/blogposts/mvcpreview4/step26.png

    Nous pouvons changer le HTML qui affiche l’erreur de façon à ce qu’il soit plus amical en ajoutant l’attribut [HandleError] à notre contrôleur ou à une méthode action de notre contrôleur :

    http://www.scottgu.com/blogposts/mvcpreview4/step9.png

    Le filtre HandleError va trapper toutes les exceptions (incluant les erreurs lance lorsque les vues template sont procédées), et affiche une réponse vue custom Error lorsqu’elles ce produise. Par défaut, il tente de résoudre un View template dans notre projet appelé "Error" pour générer la réponse. Vous pouvez placer la vue “Error” soit dans le même répertoire que vos autres vues spécifiques aux contrôleurs (par exemple: \Views\Test pour le contrôleur Test ci-haut), ou à l’intérieur du répertoire\Views\Shared (il va chercher tout d’abord pour une vue d’erreur spécifique au contrôleur et par la suite s’il ne trouve rien, il cherchera dans le répertoire partagé qui contient les vues partagées au sein de tous les contrôleurs).

    Visual Studio ajoute maintenant automatiquement un View Template “Error” pour vous dans le répertoire \Views\Shared lorsque vous créer un nouveau projet ASP.NET MVC et ce, à compté de la Preview 4:

    http://www.scottgu.com/blogposts/mvcpreview4/step11.png

    Lorsque nous ajoutons un attribut [HandleError] à notre TestController, ceci à pour effet d’afficher par défaut une page d’erreur HTML aux usagers distants (remarquez que la page fait l’utilisation du template master page du projet afin que le message d’erreur soit intégré au site).  Vous pouvez évidemment personnaliser le View Template « Error »  pour afficher n’importe quel code HTML que vous voulez ou un message plus amical – ci-bas, un exemple de qui est fourni à la base :

     http://www.scottgu.com/blogposts/mvcpreview4/step12.png

    Dans le but d’aider les développeurs, le View Template « Error »  fourni avec le nouveau template de projet dans Visual Studio est programme de sorte à afficher des traces additionnelles du stack lorsque vous exécutez l’application localement:

    http://www.scottgu.com/blogposts/mvcpreview4/step13.png

    Vous pouvez désactiver cette fonction soit en supprimant le code directement dans le template ou en activant <customErrors> à "off" dans le fichier web.config.

    Par défaut, le filtre [HandleError] vas trapper et gérer toutes les exceptions qui peuvent être lancé durant la requête.  Vous pouvez alternativement spécifier des types d’Exceptions spécifiques que vous voulez trapper et par la suite les associer à des vues personaliser et spécifiant les propriétés "ExceptionType" et "View" de l’attribut [HandleError]:

    http://www.scottgu.com/blogposts/mvcpreview4/step15.png

    Dans le code ci-haut, j’ai décide d’afficher une vue personnaliser pour les erreurs de type SqlExceptions et NullReferenceExceptions.  Toutes les autres erreurs utiliseront alors le View Template par défaut.

     

    Filtre Authorize

    Le filtre [Authorize] offre une façon de déclarer de façon déclarative un contrôle de sécurité d’accès sur un contrôleur ou une méthode action. Il vous permet d’indiquer qu’un usager doit être connecté ou de façon optionnelle qu’il s’agit d’un usager spécifique ou faisant parti d’un rôle de sécurité spécifique afin d’avoir accès. Le filtre fonctionne avec tous les types d’authentification (incluant Windows ainsi que l’authentification Forms), et support le renvoi automatique des usagers anonyme vers un formulaire de login au besoin.

    Pour en faire l’essai, ajoutez un filtre [Authorize] à la section "About" action dans le HomeController créer par défaut avec :

    http://www.scottgu.com/blogposts/mvcpreview4/step16.png

    Déclarer un attribut [Authorize] comme ci-haut signifie qu’un usager doit être connecté au site afin qu’il puisse faire une requête de la section “About” action. Losrqu’un usager non connecté tente d’atteindre l’URL /Home/About, il se verra bloqué l’accès. Si le site web est configuré pour utiliser l’authentification de type Windows, ASP.NET vas automatiquement authentifier l’usager avec ces paramètres d’identité Windows et s’il n’y à pas d’erreur, ils seront autorisés à poursuivre. Si l’application web est configurée pour utiliser l’authentification de type Forms, l’attribut [Authorize] va automatiquement rediriger l’usager à la page de login afin de les authentifier (par la suite il aura accès):

    http://www.scottgu.com/blogposts/mvcpreview4/step17.png

    L’attribut [Authorize] vous permet de façon optionnelle de donner accès à seulement certains usagers et / ou certains rôles. Par exemple, je si je voulais limiter l’accès à la section “About” action à Bill Gates et moi je pourrais écrire:

    http://www.scottgu.com/blogposts/mvcpreview4/step18.png

    Typiquement pour toutes les applications importantes, vous ne voulez pas avoir à inclure des noms d’usagers dans le code source. Faire l’emploi de concept de plus haut niveau comme les “rôles” pour définir des permissions, et par la suite associer les usagers aux “rôles” séparément (par exemple: en utilisant, active directory ou une base de données pour stocker les associations).  L’attribut [Authorize] simplifie l’utilisation de rôles pour le contrôle d’accès sur les contrôleurs et les actions en utilisant la propriété "Roles":

    http://www.scottgu.com/blogposts/mvcpreview4/step19.png

    L’attribut [Authorize] n’a pas de dépendance à un mécanisme de gestion d’identité des usagers ou de gestion de rôles. Au lieu de cela, il fonctionne avec l’objet ASP.NET “User” qui est extensible et qui permet de travailler avec n’importe quel système de gestion d’identité.

     

    La classe AccountController

    J’ai mentionné un peu plus haut que l’attribut [Authorize] peut être utilisé avec n’importe quel mécanisme d’authentification ou de gestion d’identité. Vous pouvez écrire ou utiliser n’importe quel contrôle UI de connexion ou / et de gestion de noms d’usager / mot de passe pour interagir avec ce dernier.

    Afin de vous aider à démarrer, le template de projet ASP.NET MVC dans Visual Studio comprend maintenant un "AccountController" préconçu ainsi que les vues associées qui implémente le système forms-authentication membership et comporte les fonctions de connexion, déconnexion, création de nouveaux usagers, et changements de mots de passe.  Tous les View Template peuvent être facilement personnalisés indépendamment de la classe AccountController ou de son implémentation:

    http://www.scottgu.com/blogposts/mvcpreview4/step20.png

    Le template Site.master comprend maintenant un UI dans le coin supérieur droit qui permet les connexions et déconnexions.  Lorsque vous utilisez les authentifications forms-based, il vous demandera de vous connecter si vous n’êtes pas déjà authentifié:

    http://www.scottgu.com/blogposts/mvcpreview4/step21.png

    Et il affiche un message de bienvenue ainsi qu’un lien pour la déconnexion si vous êtes authentifié sur le site:

    http://www.scottgu.com/blogposts/mvcpreview4/step22.png

    Cliquer le lien de connexion redirige l’usager sur la page de connexion comme ci-bas qu’il peut utiliser pour s’authentifier :

    http://www.scottgu.com/blogposts/mvcpreview4/step23.png

    Les nouveaux usagers peuvent cliquer le lien “register” afin de créer un nouveau compte:

    http://www.scottgu.com/blogposts/mvcpreview4/step24.png

    L’affichage et la gestion d’erreur sont aussi inclus :

    http://www.scottgu.com/blogposts/mvcpreview4/step25.png

    La classe AccountController qui est ajoutée aux nouveaux projets utilise les fonctions natives de l’API ASP.NET Membership pour faire la sauvegarde et la gestion des paramètres de connexion des usagers (le système de Membership utilise un API provider qui permet tout à type de stockage back-end de s’intégrer et ASP.NET inclut un provider préconcut pour ActiveDirectory et SQL serveur). Si vous ne voulez pas utiliser le système natif de Membership, vous pouvez conserver les mêmes signatures pour l’action AccountController, View templates, la logique de ticket Forms Authentication, et juste remplacer la logique du compte usager au sein de la classe AccountController. Pour la prochaine Preview d’ ASP.NET MVC nous planifions de faire l’encapsulation la logique d’interaction entre l’AccountController et le système d’identification des usagers derrière une interface qui rendras plus facile l’intégration de votre propre système de stockage (sans avoir à implémenter un Membership provider complet) et aussi faciliter l’exécution de test unitaire.

    Notre objectif est d’offrir aux gens une belle façon de débuter rapidement et par le fait même de leur permettre d’avoir un système de sécurité fonctionnel d’un bout à l’autre dès qu’ils créer un nouveau projet.

     

    Tester les TempData

    Un dernier détail concernant ce premier post portant sur la Preview 4 est que des améliorations sont faites à la classe Controller afin de faciliter les tests unitaires de la collection TempData. La propriété TempData vous permet de stocker les données afin de rendre persistantes les requêtes futures des usagers. Elle à la sémantique de duré seulement le temps d’une requête future (après quoi elle est supprimée). Ceci est typiquement utilisé dans les scénarios MVC où vous voulez performer une redirection côté-client afin de changer l’URL dans le navigateur, et que vous voulez une façon simple de stockée les données scratch.

    Avec les Preview précédentes d’ASP.NET MVC, vous deviez faire le mocking d’objets afin de tester la collection.  Avec la Preview 4 vous n’avez plus rien à faire de cela. Vous pouvez maintenant ajouter et vérifier les objets au sein du Controller de la collection TempData directement dans vos tests unitaires (par exemple: populer la propriété TempData d’un contrôleur avant d’appeler sa méthode action, ou de vérifier que l’action a mis à jour les TempData après le retour de l’action). La sémantique actuelle de stockage de la collection TempData est maintenant encapsulée dans une propriété TempDataProvider. 

     

    Conclusion

    J’espère que le post ci-haut offre une vue d’ensemble sur le nombre de nouvelles fonctionnalités et changements qui arrive avec la Preview 4 d’ASP.NET MVC. Mon prochain post sur ASP.NET MVC couvrira les nouvelles fonctionnalités AJAX qui ont été ajoutés ainsi que les avantages qu’elles comportent.

    J'espère que cela aide,

    Scott

     Alexandre Mensi - Article original par Scott Guthrie