Microsoft.AspNet.Identity.EntityFramework - Champs UserIdentity et RoleIdenity Id

Question

Microsoft.Aspnet.Identity.EntityFramework - Les objets UserIdentity et RoleIdEnity ont des champs d'ID de la chaîne de type, et donc les tableaux créés ont des types de données nvarchar (128).

Ces propriétés Id d'objets ne devraient-elles pas être de type System.Guid et la base de données n'a-t-elle pas des types de données d'identifiant unique ?Pourquoi ne le sont-ils pas ?Un GUID est inséré lors de la création d’un nouvel utilisateur et d’un rôle.

Answer 1

Hao Kung de l'équipe ASP.NET a écrit cela dans un commentaire sur ce question sur Comment changer idTapez à int.

Nous avons donc décidé des clés de chaîne d'éviter de devoir traiter avec des problèmes de sérialisation clés, la mise en œuvre par défaut EF aurait pu utiliser INTS comme clé primaire, les GUID n'étaient qu'un moyen simple de générer une clé de chaîne unique aléatoire.

Answer 2

C'est probablement parce que l'API est indépendante du fournisseur de stockage, de sorte que les types de champs conservés aussi génériques que possible: http://blogs.msdn.com/b/webdev/archive/2013/06/27/introducing-asp-net-Ientidy-Membership-System-for-asp-net-Applications.aspx

"Si les exigences de votre application sont que ces informations peuvent être stockées dans un mécanisme de stockage différent, tel que SharePoint, un service de table Azure, aucune base de données SQL, etc. Il est maintenant possible de brancher différents fournisseurs de stockage."

Answer 3

Une autre raison pour laquelle un ID utilisateur de chaîne peut être que les chaînes sont codées en dur dans l'API de revendications, en particulier : Microsoft.AspNet.Identity.IdentityExtensions.GetUserId, qui utilise System.Security.Claims.Value, qui renvoient tous deux des chaînes.