Pourquoi Asp.Net l'Identité IdentityDbContext une Boîte Noire?
Il y a beaucoup de confusion, il semble autour de IdentityDbContext.
Si nous créer la Base de données deux Contextes dans notre application, l'un pour l'Identité et l'un de nos affaires personnalisée de données, la Base de données d'Identité Contexte hérite de IdentityDbContext alors que notre métier personnalisé des données hérite de DbContext.
Donc, nous allons ajouter ce qui suit dans un contrôleur:
private MyDbContext db = new MyDbContext();
private ApplicationDbContext identityDb = new ApplicationDbContext();
Et le suivant à une méthode de l'Indice dans le contrôleur:
var thingsInMyBusinessDb = db.Things.ToList();
var usersInIndentityDb = identityDb.AspNetUsers.ToList(); //THIS WILL HAVE AN ERROR
var roles = identityDb.AspNetRoles.ToList(); //ERROR
Vous remarquerez également que les tables de l'Identité de la Base de données ne sont pas disponibles. Pourquoi est-ce?
Actuellement que de 2.0.0-beta1 il est un des Utilisateurs et des Rôles des éléments, mais je me serais attendu à la réelle tables à disposition. Et pourquoi pas? Que faire si j'ai envie de faire AspNetUserRoles
Semble que beaucoup de confusion et de problèmes avec Asp.Net l'Identité serait aller loin si elle était traitée comme n'importe quelle base de données de contexte dans le Cadre de l'Entité.
Vous devez vous connecter pour publier un commentaire.
La
ApplicationDbContext
'sUsers
etRoles
propriétés sont mappées à laAspNetUsers
etAspNetRoles
les tables, et le reste des entités (Claims
,Logins
,UserRoles
) sont mappés automatiquement via les propriétés de navigation. Autant que je sache, la préfixation de noms de table avec "Réseau" sont la seule coutume mappages dansApplicationDbContext
, tout le reste est juste Entity Framework Code First conventions.Si vous avez besoin d'un accès direct aux tables via le
ApplicationDbContext
, vous pouvez le faire comme ceci...Vous pouvez accéder à l'un des rôles de l'utilisateur, des réclamations et des connexions via les propriétés de navigation sur le
IdentityUser
entité (à partir de laUsers
DbSet
). Si vous voulez interroger directement, ajouter explicitement dans lesDbSet
s sur le contexte...Et de les interroger comme ça...
ASP.NET Identité 2.0 expose
Users
etRoles
IQueryable
s sur le Gestionnaire de classes pour des raisons de commodité, mais il ne fournit pas toutes les fonctionnalités ajoutées sur ce qui était disponible à partir de la DbContext.ApplicationUser
, ils doivent s'affichent. Si vous les avez ajoutées sur les rôles d'utilisateur, vous avez dû créer une classe (ApplicationUserRole
) qui hérite deIdentityUserRole
; dans ce cas, elle doit êtrepublic DbSet<ApplicationUserRole> UserRoles { get; set; }
et les propriétés personnalisées doivent être disponibles.IdentityRole
à unApplicationRole
. J'ai juste essayé la coulée d'uneIdentityUserRole
à unApplicationUserRole
et ma propriété personnalisée, n'était pas accessible. Bien que si vous êtes à la personnalisation des classes au-delà de laApplicationUser
, vous pouvez attendre ASP.NET Identité 2.0. Il a une nouvelleIdentityDbContext<TUser, TRole, TKey, TUserLogin, TUserRole, TUserClaim>
de la classe de base qui vous permet de spécifier toutes vos entités personnalisées.public class ApplicationDbContext : IdentityDbContext<ApplicationUser, ApplicationRole, int, ApplicationLogin, ApplicationUserRole, ApplicationClaim>
(int
(oustring
) est le type de l'Utilisateur de la clé primaire).Il y a un malentendu fondamental sur la manière dont
DbContext
œuvres. Les noms de propriété de votreDbSet
s dans votre contexte ne pas correspondent à des noms de table. Si quoi que ce soit, le nom de la table est basé sur le nom de la classe de l'entité réelle, mais même cela peut être substituée. Un parfait exemple est bien sûr, de votre classe d'utilisateur, qui est par défautApplicationUser
, mais va résider dans une table appeléeAspNetUsers
.Tous les
DbSet
propriétés dans votre contexte, déterminer est de l'API que vous utilisez pour accéder aux données via Entity Framework.IdentityDbContext
implémenteDbSet
propriétés nomUsers
,Roles
, etc. Donc, c'est comment accéder à ces données, pas via le nom de la table (c'est à direcontext.Users
).De plus, si vous n'êtes pas satisfait d'avoir deux contextes, vous n'avez pas à garder que deux. Faites votre contexte principal hériter de
IdentityDbContext<ApplicationUser>
au lieu deDbContext
et de tuer le scaffolding version.Même si l'identité des tables dans la base de données est nommé avec
aspnet
préfixe, vous pouvez toujours modifier. Mais pas toujours le nom de la table dans la base de données ne seront pas ceux que vous verrez lors de l'accès à partir deDbContext
. Vous aurez besoin de travailler avec des noms, qui est généré par le cadre. Mais cela peut être changé aussi. Voir L'identité du Modèle de Données avec Entity Framework Couramment.Il y a certainement beaucoup de confusion autour de IdentityDbContext, une recherche rapide autour et vous trouverez beaucoup de questions à ce sujet.
ASP.NET l'Identité DbContext confusion
Comment puis-je changer les noms de table lors de l'utilisation de Visual Studio 2013 AspNet Identité?
Fusion MyDbContext avec IdentityDbContext
La réponse à toutes ces questions, nous devons d'abord comprendre comment IdentityDbContext œuvres. Pour clarifier les choses, nous devons prendre en considération que IdentityDbContext est juste une classe héritée de DbContext et pas une boîte noire!
Jetons un coup d'oeil à IdentityDbContext source:
Basé sur le code source de tout ce que vous avez à faire est de créer un DbContext qui hérite de IdentityDbContext et d'avoir accès aux classes.
Si vous souhaitez étendre les classes ont un coup d'oeil à AspNet Identité 2.0 Extensible Modèle De Projet