2014-08-29 14 views
6

Kiedy używam pierwszego kodu ASP.NET Identity, chcę generować kolumny w tabeli AspNetUsers na swój własny sposób. Nie muszę przechowywać wielu kolumn z wartościami null. Potrzebuję tylko kolumn Id, SecurityStamp i UserName. Tylko wpis, który znalazłem jest tutaj: AspNet Identity 2.0 Email and UserName duplication, ale nadal nie jest dostępny (z powodu błędu w komentarzu Santosh).ASP.NET Identity - usuń kolumnę z tabeli AspNetUsers

Czy ktoś może mi powiedzieć, jak rozwiązać ten problem?

EDYCJA: Czy można nawet usunąć niektóre z tych kolumn/właściwości?

Dzięki

+3

może nie trzeba tych val ale czy jesteś pewien, że asp.net nie potrzebuje ich do poprawnego działania? –

+0

Zdaję sobie sprawę, że może istnieć pewien związek, Mam edytować moje pytanie – exeq

+1

Jeśli chcesz mieć własne niestandardowe tabele, to nie używaj 'Identity.Entityframework' – Shoe

Odpowiedz

3

Krótka odpowiedź brzmi: nie, nie bez toczenia własną implementację. Lub możesz poczekać na ich otwarcie kodu źródłowego asp.net na codeplex. Kto wie, ile to potrwa.

Domyślna implementacja obejmuje wszystkie te nieużywane kolumny (patrz poniżej).

// Summary: 
//  Default EntityFramework IUser implementation 
// 
// Type parameters: 
// TKey: 
// 
// TLogin: 
// 
// TRole: 
// 
// TClaim: 
public class IdentityUser<TKey, TLogin, TRole, TClaim> : IUser<TKey> 
    where TLogin : Microsoft.AspNet.Identity.EntityFramework.IdentityUserLogin<TKey> 
    where TRole : Microsoft.AspNet.Identity.EntityFramework.IdentityUserRole<TKey> 
    where TClaim : Microsoft.AspNet.Identity.EntityFramework.IdentityUserClaim<TKey> 
{ 
    // Summary: 
    //  Constructor 
    public IdentityUser(); 

    // Summary: 
    //  Used to record failures for the purposes of lockout 
    public virtual int AccessFailedCount { get; set; } 
    // 
    // Summary: 
    //  Navigation property for user claims 
    public virtual ICollection<TClaim> Claims { get; } 
    // 
    // Summary: 
    //  Email 
    public virtual string Email { get; set; } 
    // 
    // Summary: 
    //  True if the email is confirmed, default is false 
    public virtual bool EmailConfirmed { get; set; } 
    // 
    // Summary: 
    //  User ID (Primary Key) 
    public virtual TKey Id { get; set; } 
    // 
    // Summary: 
    //  Is lockout enabled for this user 
    public virtual bool LockoutEnabled { get; set; } 
    // 
    // Summary: 
    //  DateTime in UTC when lockout ends, any time in the past is considered not 
    //  locked out. 
    public virtual DateTime? LockoutEndDateUtc { get; set; } 
    // 
    // Summary: 
    //  Navigation property for user logins 
    public virtual ICollection<TLogin> Logins { get; } 
    // 
    // Summary: 
    //  The salted/hashed form of the user password 
    public virtual string PasswordHash { get; set; } 
    // 
    // Summary: 
    //  PhoneNumber for the user 
    public virtual string PhoneNumber { get; set; } 
    // 
    // Summary: 
    //  True if the phone number is confirmed, default is false 
    public virtual bool PhoneNumberConfirmed { get; set; } 
    // 
    // Summary: 
    //  Navigation property for user roles 
    public virtual ICollection<TRole> Roles { get; } 
    // 
    // Summary: 
    //  A random value that should change whenever a users credentials have changed 
    //  (password changed, login removed) 
    public virtual string SecurityStamp { get; set; } 
    // 
    // Summary: 
    //  Is two factor enabled for the user 
    public virtual bool TwoFactorEnabled { get; set; } 
    // 
    // Summary: 
    //  User name 
    public virtual string UserName { get; set; } 
} 
+0

Dzięki. Czy uważasz, że problemem jest posiadanie 100 000 rekordów, a nawet więcej, w tej tabeli z tymi wszystkimi zerami pól? Nie chcę tworzyć niestandardowych tabel, ponieważ używam funkcjonalności logowania w ASP.NET Identity. – exeq

+0

Nie jestem DBA w żaden sposób, ale nie sądzę, że jest to duży problem. Tabele są indeksowane i poprawnie wpisane, więc powinieneś być w porządku. Inną opcją może być rozważenie tego projektu: https://github.com/brockallen/BrockAllen.IdentityReboot. Nie używałem go osobiście, ale może dać ci elastyczność, której pragniesz. – drneel

3

Właściwie możesz po prostu skonfigurować swój podmiot na OnModelCreating swojej klasy kontekstu.

protected override void OnModelCreating(DbModelBuilder modelBuilder) 
{ 
    modelBuilder.Entity<IdentityUser>().Ignore(u => u.AccessFailedCount); 
    //and so on... 
} 

Albo jeśli aplikacja ma osobny plik dla każdej konfiguracji (wich co polecam), można zrobić tak:

public class ApplicationUserEntityTypeConfiguration : EntityTypeConfiguration<ApplicationUser> 
{ 
    public ApplicationUserEntityTypeConfiguration() 
    { 
     Ignore(p => p.AccessFailedCount); 
     //And so on.. 
    } 
} 
+1

Wyrzuca wyjątek, kiedy mam zamiar dodać migrację. –

16

Właściwie można zignorować pola, po prostu trzeba skonfigurować jednostkę OnModelCreating w swoim podręcznym klasy jako:

protected override void OnModelCreating(DbModelBuilder modelBuilder) 
{ 
     base.OnModelCreating(modelBuilder); 
     modelBuilder.Entity<IdentityUser>().Ignore(c => c.AccessFailedCount) 
              .Ignore(c=> c.LockoutEnabled) 
              .Ignore(c=>c.LockoutEndDateUtc) 
              .Ignore(c=>c.Roles) 
              .Ignore(c=>c.TwoFactorEnabled);//and so on... 

     modelBuilder.Entity<IdentityUser>().ToTable("Users");//to change the name of table. 

} 
+0

Czy możesz dokładniej określić, gdzie znajduje się klasa "kontekst"? – webworm

+1

Aby odpowiedzieć na własne pytanie, klasa kontekstu to ApplicationDbContext – webworm

+0

@webworm Tak, masz rację. –

Powiązane problemy