asp.net core identity




Warum verwenden die ASP.NET Identity-Schnittstellen Zeichenfolgen für Primärschlüssel und Fremdschlüssel? (2)

Die Absicht war, beide willkürlichen ID-Typen (dh int , guid , string ) zuzulassen, aber auch Serialisierungs- / Casting-Probleme für die id-Eigenschaft zu vermeiden.

So können Sie Ihre Schlüssel beliebig definieren und einfach die Schnittstellenmethode implementieren

public class MyUser : IUser {
  public int Id { get; set; }
  string IUser.Id { get { return Id.ToString(); } }
}

Ich betrachte die Schnittstellen zu den neuen ASP.NET-Identitätsklassen und der Datenbank, die mit Entity Framework Code First erstellt wird. Ich verwende das Visual Studio 2013 RC.

Auf den ersten Blick sieht das Datenbankschema einigermaßen normal aus:

Alle Schlüssel sind jedoch NVARCHAR (128).

Aus irgendeinem verrückten Grund ist AspNetUserSecrets.Id eine PK, die so aussieht, als könnte sie auf mehr als einen Datensatz in der AspNetUsers Tabelle AspNetUsers . Bedeutet dies, dass mehrere AspNetUsers dasselbe Passwort verwenden müssen?

Wenn ich mir die Schnittstellen ansehen, die Sie implementieren müssen, sind dies alles Strings ...

public class User : IUser
{
    public string Id { get; set; }
    public string UserName { get; set; }
}

public class UserSecret : IUserSecret
{
    public string UserName { get; set; }
    public string Secret { get; set; }
}

public class UserRole : IUserRole
{
    public string UserId { get; set; }
    public string RoleId { get; set; }
}

public class UserClaim : IUserClaim
{
    public string UserId { get; set; }
    public string ClaimType { get; set; }
    public string ClaimValue { get; set; }
}

public class UserManagement : IUserManagement
{
    public string UserId { get; set; }
    public bool DisableSignIn { get; set; }
    public DateTime LastSignInTimeUtc { get; set; }
}

public class Tokens : IToken
{
    public string Id { get; set; }
    public string Value { get; set; }
    public DateTime ValidUntilUtc { get; set; }
}

public class UserLogin : IUserLogin
{
    public string UserId { get; set; }
    public string LoginProvider { get; set; }
    public string ProviderKey { get; set; }
}

public class Role : IRole
{
    public string Id { get; set; }
    public string Name { get; set; }
}

Ich muss mich damit abfinden, dass ich dies möglicherweise mit Strings für PK- und FK-Beziehungen implementieren muss.

Aber ich würde wirklich gerne wissen, warum es so gebaut ist ...?

BEARBEITEN: Die Zeit ist vergangen und es gibt jetzt Artikel darüber, wie die asp.net-Identität erweitert werden kann, um int (oder guid) -Felder zu verwenden:

http://www.asp.net/identity/overview/extensibility/change-primary-key-for-users-in-aspnet-identity


Hinzufügen zu dem, was Hao sagte:

  1. Die Identity-Laufzeit bevorzugt Zeichenfolgen für die Benutzer-ID, weil wir nicht die richtige Serialisierung der Benutzer-IDs ermitteln möchten (wir verwenden Zeichenfolgen auch für Ansprüche aus demselben Grund), z. B. alle (oder die meisten) Die Identitätsschnittstellen verweisen auf die Benutzer-ID als Zeichenfolge.
  2. Personen, die die Persistenzschicht anpassen, z. B. die Entitätstypen, können wählen, welchen Typ sie für Schlüssel verwenden möchten. Sie besitzen jedoch eine eigene String-Darstellung der Schlüssel.
  3. Standardmäßig verwenden wir die Zeichenfolgendarstellung von GUIDs für jeden neuen Benutzer. Dies ist jedoch nur deshalb möglich, weil wir damit auf einfache Weise eindeutige IDs generieren können.






asp.net-identity