Obtenir l'entité utilisateur actuelle en ASP.Net MVC

Question

J'ai cet exemple de code :

<%@ Control Language="C#" Inherits="System.Web.Mvc.ViewUserControl" %>
<%
    if (Request.IsAuthenticated) {
%>
        Welcome <b><%= Html.Encode(Page.User.Identity.Name) %></b>!

Le problème, c'est que je mets le numéro de l'utilisateur id et non le nom dans le champ "nom d'utilisateur" :

User user = _userRepository.Get(...);
FormsAuthentication.RedirectFromLoginPage(user.Id.ToString(), false);

Le premier exemple de code est inclus dans la vue principale et apparaît donc dans toutes les vues. Ce que je ne comprends pas, c'est comment transmettre à cette vue l'entité modèle User, puisque je ne l'appelle pas directement.

Modifier : Existe-t-il un point unique dans le traitement d'une requête HTTP où je peux intervenir pour injecter l'objet modèle User dans la ViewData ? Je ne voudrais pas toucher à chaque contrôleur+action pour y parvenir.

Answer 1

La solution la plus courante consiste à stocker l'utilisateur dans une variable de session. Je dirais que c'est aussi le moyen le plus populaire, même dans ASP.NET MVC.

Dans une classe utilitaire ou une classe de base de page/usercontrol personnalisée :

const string _userSessionKey = "CurrentUser_";
public UserModelType CurrentUser
{
    var user = HttpContext.Current.Session[_userSessionKey] as UserModelType;
    if(user == null)
    {
        if(HttpContext.Current.User.Identity.IsAuthenticated)
        {
            //new UserService() or DependencyContainer.Resolve<IMembershipService>()
            user = new MembershipService().GetUserById(HttpContext.Current.User.Identity.Name);
            HttpContext.Current.Session[_userSessionKey] = user;
        }
    }

    return user;
}

Je sais !
C'est trop classique et probablement pas MVC-ish, mais je vois habituellement des implémentations similaires.

La chose la plus importante pour que cela reste compatible avec MVC est que ce code soit mieux appelé depuis un contrôleur. Vous pouvez utiliser un contrôleur partiel qui produit un contrôle utilisateur ou autre (il y a une méthode RenderAction que je considère comme l'une des meilleures parties). Ainsi, la vue ne reçoit que le nom de l'utilisateur ou le modèle d'utilisateur qui n'appelle pas ce code directement. C'est pourquoi une classe utilitaire ici est bien meilleure qu'une classe de base de page/contrôleur, mais il y a les options en général.

Si vous voulez les meilleurs produits, vous devriez chercher quelque chose comme.. :

Kit de démarrage pour membres ASP.Net MVC

Answer 2

Ce que j'ai décidé, c'est de créer une classe de modèle de vue principale dont dérivent presque tous les modèles spécifiques à la vue. Le modèle maître contient les informations dont chaque vue peut avoir besoin. J'essaie de garder ces informations très petites et de les mettre en cache dans la session afin que le remplissage du modèle ne soit pas une opération intensive. Le modèle implémente une interface afin que chaque modèle spécifique à une vue puisse également implémenter cette interface et, ainsi, je peux facilement créer une vue fortement typée qui accepte l'interface si je ne me soucie que des informations de base. J'utilise un contrôleur de base pour tous mes contrôleurs et le code pour remplir le modèle de base est implémenté sur le contrôleur de base. Chaque modèle de vue spécifique possède un constructeur qui prend l'interface du modèle de base et copie les données dans l'instance locale.

Answer 3

Vous pouvez vous assurer que chaque contrôleur/page/contrôle implémente une classe de base dans laquelle vous exposez les données du modèle que vous recherchez.

Cela tend à devenir pénible, assez rapidement, mais il est plus propre de faire passer un ViewModel que de frapper le HttpContext depuis la page elle-même.

Edit : C'est l'un des rares cas où je serais enclin à utiliser ViewData["username"] et à l'utiliser dans la MasterPage, au moins de cette façon, seule la classe de base a besoin de le remplir et vous pouvez éviter de connaître l'authentification à travers vos contrôleurs.