Wie man Entity Framework mit IdentityDbContext mockt?

Question

Ich arbeite an einer ASP.NET MVC Web App mit individueller Authentifizierung, um Details über Benutzerautos zu speichern. Ich werde die Web-App testen müssen, indem ich das Entityframework verspotze, also habe ich gelesen, dass ich eine Schnittstelle für die Klasse ApplicationDbContext implementieren muss.

Dies ist mein erster Versuch, Entity Framework zu verwenden, und ich wollte nur überprüfen, ob meine ApplicationDbContext Klasse und Schnittstelle geeignet sein wird, das Framework beim Komponententest zu verspotten?

public interface IApplicationDbContext : IDisposable 
{ 
    IDbSet<ApplicationUser> Users { get; set; } 
    DbSet<CarModel> Cars { get; set; } 
    int SaveChanges(); 
    void MarkAsModified(CarModel car); 
} 

public class ApplicationDbContext : IdentityDbContext<ApplicationUser>, IApplicationDbContext 
{ 
    public ApplicationDbContext() 
     : base("ApplicationDb", throwIfV1Schema: false) 
    { 
    } 

    public static ApplicationDbContext Create() 
    { 
     return new ApplicationDbContext(); 
    } 

    public DbSet<CarModel> Cars { get; set; } 

    public override IDbSet<ApplicationUser> Users { get; set; } 

    public void MarkAsModified(CarModel car) 
    { 
     Entry(car).State = EntityState.Modified; 
    } 
} 

Einige der Klassen wurden durch Autokorrektur mit Visual Studios "Quick Actions" erstellt. Könnte jemand erklären, warum die ApplicationUser Modelle erfordern IDbSet, aber die CarModels erfordern nur DbSet, und warum die Users in der Klasse ApplicationDbContext erfordern eine Überschreibung?

Answer 1

Könnte jemand erklären, warum die ApplicationUser Modelle IDbSet erfordern, aber die Automodelle erfordern nur DbSet

IdentityDbContext class nach Design verwendet IDbSet<TEntity> für beide Users und Roles Eigenschaften

public virtual IDbSet<TUser> Users { get; set; } 
public virtual IDbSet<TRole> Roles { get; set; } 

In Ihrem Fall, dass Sie kann dem gleichen Muster folgen

public virtual IDbSet<CarModel> Cars { get; set; } 

und aktualisieren Sie Ihre Schnittstelle als auch passen können

public interface IApplicationDbContext : IDisposable { 
    IDbSet<ApplicationUser> Users { get; set; } 
    IDbSet<CarModel> Cars { get; set; } 
    int SaveChanges(); 
    void MarkAsModified(CarModel car); 
} 

Die Schnittstelle dann sicher für Ihre isoliert Unit-Tests verspottet werden, sofern die Schnittstelle in das Thema zu test injiziert wurde.

und warum die Benutzer in der ApplicationDbContext-Klasse eine Außerkraftsetzung erfordern?

Es braucht nicht tatsächlich als Gattungs der Klasse außer Kraft gesetzt werden (dh IdentityDbContext<ApplicationUser>) würde bereits die Eigenschaft, um die zur Verfügung gestellt ApplicationUser Art folgen. Sie hätten es genauso gut auslassen können.

public class ApplicationDbContext 
    : IdentityDbContext<ApplicationUser>, IApplicationDbContext { 

    public ApplicationDbContext() 
     : base("ApplicationDb", throwIfV1Schema: false) { 
    } 

    public static ApplicationDbContext Create() { 
     return new ApplicationDbContext(); 
    } 

    public virtual IDbSet<CarModel> Cars { get; set; } 

    public void MarkAsModified(CarModel car) { 
     Entry(car).State = EntityState.Modified; 
    } 
}