web-dev-qa-db-fra.com

Quelle est la différence dans l'utilisation de UserStore et UserManager dans Asp.Net Identtity?

Je suis très nouveau sur Asp.Net Identity et soyez indulgent avec moi si cette question semble idiote. Ainsi, lorsque je lis la définition de la classe UserStore et de la classe UserManager dans le site Web de Microsoft qui se trouvent dans les liens ci-dessous, il semble que les deux classes définissent les opérations autour des utilisateurs (comme Ajouter, Rechercher, Supprimer et Modifier). Alors, quand dois-je utiliser l'un sur l'autre?:

https://msdn.Microsoft.com/en-us/library/dn315446 (v = vs.108) .aspxhttps://msdn.Microsoft.com/en-us /library/dn613290(v=vs.108).aspx

c#asp.net-mvcasp.net-identityowin
25
MinhNguyen

Les choses sont assez compliquées là-bas et auraient pu être plus faciles.

UserManger est le ... gestionnaire. Il n'interagit pas vraiment avec le stockage, la base de données. C'est ce que fait le UserStore.

En fait, UserManager a un constructeur qui a besoin d'un UserStore.

Pourquoi auriez-vous besoin d'un objet différent pour gérer les utilisateurs? Eh bien, la raison principale est que vous pouvez décider de ne pas utiliser EF et de créer votre propre magasin d'utilisateurs.

Les choses deviennent plus claires lorsque vous essayez d'implémenter votre propre fournisseur de stockage. Je l'ai fait et mon code peut être téléchargé depuis github .

Il s'agit du serManager . Comme vous pouvez le voir, il n'y a pas grand-chose là-dedans. Juste quelques lignes de code pour configurer le validateur.

serStore au contraire, est assez grand. Dans cet exemple, j'ai implémenté quelques interfaces et remplacé quelques méthodes. C'est ce que vous feriez si vous souhaitez personnaliser l'interaction avec la base de données et/ou étendre vos classes.

Normalement, vous n'interagissez pas avec le UserStore et en fait il est caché. Il vous suffit de le créer et de le transmettre au UserManager et ... de l'oublier.

Vous pouvez toujours personnaliser votre UserManager et exposer le UserStore:

public class UserManager : UserManager<User, int>
{
    public UserManager(IUserStore<User, int> store): base(store)
    {
        this.Store = store;
    }

    public IUserStore<User, int> Store { get; set; }

}

et, peut-être, outrepasser certaines des méthodes:

public class UserManager : UserManager<User, int>
{
    public UserManager(IUserStore<User, int> store): base(store)
    {
        this.Store = store;
    }

    public IUserStore<User, int> Store { get; set; }

    public override System.Threading.Tasks.Task<IdentityResult> CreateAsync(User user)
    {
        return base.CreateAsync(user);
    }
}

mais ce serait inutile à moins que vous n'ayez à faire une personnalisation particulière.

Supposons que vous souhaitiez créer un utilisateur à l'aide du magasin au lieu du gestionnaire. Vous pouvez faire quelque chose comme ça:

await this.UserManager.Store.CreateAsync(new Custom.Identity.User() { UserName = "LeftyX" });

et ça marcherait.

Dans la classe ci-dessus, comme vous pouvez le voir, j'ai remplacé le CreateAsync dans le UserManager.
Cette méthode appelle UserStore.CreateAsync() et en fait, vous devez appeler la méthode de base CreateAsync:

public override System.Threading.Tasks.Task<IdentityResult> CreateAsync(User user)
   {
       return base.CreateAsync(user);
   }

Si vous ne le faites pas et, par exemple, retournez null à la place, le UserStore.CreateAsync Ne sera pas appelé et l'utilisateur ne sera pas créé.

Cela a du sens à la fin.

Je suppose que la meilleure façon de comprendre comment ce framework fonctionne est d'essayer de personnaliser/implémenter votre solution avec votre propre stockage et de voir comment toutes les classes interagissent les unes avec les autres.

L'exemple projet n'interagit pas avec une base de données mais utilise un stockage json. C'est très facile à déboguer. Essayez-le et les choses seront plus claires à un moment donné.

42
LeftyX

Je regardais le didacticiel sur l'identité sur YouTube, et je pense que cette capture d'écran pourrait aider:

Managers vs Stores

Donc, UserManager est la classe réelle avec laquelle vous devez travailler, mais il ne sait pas comment stocker et récupérer les données de la base de données. il ne sait même pas d'où vont et viennent les données.

Pour ces choses, il utilise UserStore et lui dit par exemple: "Hey UserStore, j'ai un nouvel utilisateur qui doit être enregistré pour une utilisation future, je ne sais pas où vous allez l'enregistrer et comment vous allez le faire il suffit de le garder pour moi "

Ensuite, le UserStore effectue le travail réel, par exemple, où les données doivent-elles être enregistrées? quelle base de données? et comment? celui par défaut utilise EF et SQL Server, donc si vous souhaitez utiliser une autre base de données, par exemple MySQL, vous aurez besoin d'un autre UserStore.

C'est l'une des fonctionnalités qui ont été ajoutées à l'identité par rapport à l'appartenance qui ne fonctionnait qu'avec SQL Server.

Le même concept est vrai pour RoleManager et RoleStore.

3
Sasan

L'identité est basée sur deux blocs principaux dans ASP.NET Identity. Il existe un gestionnaire d'authentification qui prend la forme de UserManager<T> classe. Il y a aussi le gestionnaire de magasin qui est une instance de UserStore<T>.

Différence?

Le UserStore<T> l'objet est injecté dans le gestionnaire d'authentification qui est utilisé pour identifier et authentifier le UserStore<T> identité. Le UserManager<T> la référence fait office d'authentificateur pour le UserStore<T> identité.

Détails importants

L'identité ASP.NET est basée sur la nouvelle interface Web ouverte. Cela signifie que [généralement], l'interface IAuthenticationManager déclarée dans Microsoft.Owin.Security: Lié ici , l'authentificateur injecté dans la classe et le contrôleur UserManager et essentiellement toutes les opérations qui impliquent une étape d'authentification.

Dans ce qui suit:

private async Task SignInAsync(ApplicationUser user, bool isPersistent)
{
    var identity = await UserManager.CreateIdentityAsync(user,
    DefaultAuthenticationTypes.ApplicationCookie);
    AuthenticationManager.SignIn(new AuthenticationProperties() {
    IsPersistent = isPersistent }, identity);
}

Nous pouvons remarquer que le gestionnaire d'authentification UserManager est utilisé pour vérifier l'utilisateur de l'application "UserStore" par rapport à l'identité du gestionnaire d'authentification. Extrait extrait du blog.

Conclusion Le UserManager est essentiellement la logique de domaine de votre identité ASP.NET. Le contrôleur que vous utilisez pour gérer une "connexion" ou une "identification" est transmis par un UserStore, qui MSDN: Userstore représente ...

Représente une implémentation Entity Framework d'un magasin d'utilisateurs qui prend en charge IUserStore, IUserLoginStore, IUserClaimStore et IUserRoleStore.

Une fois que le UserStore a tous les champs nécessaires pour être qualifié d'identité et que vous avez qualifié le UserManager de gestionnaire d'authentification, et une méthode de stockage du contexte ... aka IdentityDbContext ou une autre méthode de stockage des valeurs dans SQL (si utilisé), vous disposerez d'un système d'identité capable de prendre en charge les connexions.

3
Adam