Microsoft.AspNet.Identity.EntityFramework - campos UserIdentity e RoleIdenity ID

Question

Microsoft.aspnet.Identity.EntityFramework - Objetos UserIdentity e Roleidenity têm campos de identificação da string de tipo e, portanto, as tabelas criadas têm tipos de dados nvarchar (128).

Essas propriedades de ID de objetos não deveriam ser do tipo System.Guid e o banco de dados ter tipos de dados de identificador único?Por que não são?Um GUID é inserido na criação de um novo usuário e função.

Answer 1

hao kung da equipe asp.net escreveu isso em um comentário sobre este pergunta sobre como alterar o IDDigite para int.

Por isso, decidimos que as teclas de string evitem ter que lidar com os principais problemas de serialização, a implementação padrão da EF poderia ter usado os ints como a chave primária, os GUIDs eram apenas uma maneira fácil de gerar uma chave de string exclusiva aleatória.

Answer 2

É mais provável porque a API é o provedor de armazenamento independente, de modo que os tipos de campo mantidos como genéricos quanto possível: http://blogs.msdn.com/b/webdev/archive/2013/06/27/introducing-asp-net-identity-memembership-system-for-asp-net-applicações.aspx

"Se os requisitos de aplicativos forem que esta informação puder ser armazenada em um mecanismo de armazenamento diferente, como o SharePoint, o serviço de tabela do Azure, nenhum banco de dados SQL, etc. Agora é possível conectar diferentes provedores de armazenamento."

Answer 3

Outro motivo para um ID de usuário de string pode ser que as strings são codificadas na API de declarações, especificamente, Microsoft.AspNet.Identity.IdentityExtensions.GetUserId, que utiliza System.Security.Claims.Value, ambos retornando strings.