Entity FrameworkカスタムのASP .NETコアIDカスタムDbContext

Question

ASP.NETコアIDとエンティティフレームワークでドキュメントを読み込もうとしました。しかし、私はまだ賢明ではないと感じています。

私はIdentityDbContext、IdentityUser、IdentityRoleとは関係がありません。私はちょうど私の自身のDbContext実装を使用してUserManager、UserStore、RoleManager、SignInManager、および他のものの中で署名に関わるクラスで楽しく仕事をしたい。

だから、そのデフォルトASP.NETコアプロジェクトを作成した、と言われて「個人ユーザーアカウント」を使用します。今、私はDIワイヤアップがそのコントローラが "働く"ために必要とされるものを理解したいと思います。アカウントコントローラのコンストラクタを見てみると

：それとともに

public AccountController(UserManager<ApplicationUser> userManager, 
     SignInManager<ApplicationUser> signInManager, 
     IOptions<IdentityCookieOptions> identityCookieOptions, 
     IEmailSender emailSender, 
     ISmsSender smsSender, 
     ILoggerFactory loggerFactory) 

は、次の関連クラスが生成されます。

public class ApplicationUser : IdentityUser 
{ 
} 

public class ApplicationDbContext : IdentityDbContext<ApplicationUser> 
{ 
    ... 
} 

そして、いくつかの関連DI構成：

public void ConfigureServices(IServiceCollection services) 
{ 
    ... 
    services.AddDbContext<ApplicationDbContext>(options => 
     options.UseSqlServer(Configuration.GetConnectionString("DefaultConnection"))); 

    services.AddIdentity<ApplicationUser, IdentityRole>() 
     .AddEntityFrameworkStores<ApplicationDbContext>() 
     .AddDefaultTokenProviders(); 
} 

public void Configure(IApplicationBuilder app, IHostingEnvironment env, ILoggerFactory loggerFactory) 
{ 
    ... 
    app.UseIdentity(); 
} 

掘削ASP.NET Core Identityのソースコードでは、UserStoreは強制的に制約を適用しますIdentityUserにあります。

public class AuthenticationDbContext : DbContext 
{ 
    public AuthenticationDbContext(DbContextOptions options) : base(options) 
    { 
    } 

    public DbSet<ApplicationUser> ApplicationUsers { get; set; } 
    public DbSet<ApplicationRole> ApplicationRoles { get; set; } 

    protected override void OnModelCreating(ModelBuilder builder) 
    { 
     base.OnModelCreating(builder); 

     builder.Entity<ApplicationUser>(te => 
      te.HasKey(user => user.Id)); 

     builder.Entity<ApplicationRole>(te => 
      te.HasKey(role => role.Id)); 
    } 
} 

public class ApplicationRole 
{ 
    public int Id { get; set; } 
    public string UserName { get; set; } 
} 

public class ApplicationUser 
{ 
    public int Id { get; set; } 
    public Guid Guid { get; set; } 
    public string GivenName { get; set; } 
    public string FamilyName { get; set; } 
    public string MiddleName { get; set; } 
    public DateTime? DateOfBirth { get; set; } 
    public string UserName { get; set; } 
    public string EmailAddress { get; set; } 
} 

私は私が持っていた問題、例外らが記載されている場合は、この記事が長すぎるだろう：初心者のために - 私が仕事をしたい何のため

public class UserStore : UserStore<IdentityUser<string>> 

は、次のようなものです。

問題は、これをDI構成でどのように配線するのですか？

Answer 1

OK。私のAuthenticationDbContextを同じに保つことに続き、IUserStore、IRoleStoreの実装を提供し、DIを次のように構成することができます。

public class ApplicationUserStore : IUserStore<ApplicationUser>, IUserPasswordStore<ApplicationUser> 
{ 
    private readonly AuthenticationDbContext _dbContext; 

    public ApplicationUserStore(AuthenticationDbContext dbContext) 
    { 
     _dbContext = dbContext; 
    } 

    ... 

OK、私は考え出す少しを必要とし、ここで10のまたは11のメソッドの実装を提供する必要があります。 ApplicationRoleStoreも同様です。

public class ApplicationRoleStore : IRoleStore<ApplicationRole> 
{ 
    private AuthenticationDbContext _dbContext; 

    public ApplicationRoleStore(AuthenticationDbContext context, IdentityErrorDescriber describer = null) 
    { 
     _dbContext = context; 
    } 

    ... 

その後、これはとアップ配線することができます：私は、ログインをクリックしたとき

public void ConfigureServices(IServiceCollection services) 
{ 
    services.AddIdentity<ApplicationUser, ApplicationRole>() 
     .AddUserStore<ApplicationUserStore>() 
     .AddRoleStore<ApplicationRoleStore>() 
     .AddDefaultTokenProviders(); 

    services.AddTransient(c => 
      new AuthenticationDbContext(
       new DbContextOptionsBuilder() 
        .UseSqlServer(Configuration.GetConnectionString("DefaultConnection")).Options)); 

だから、アカウント・コントローラ/ログインビュー経由での署名は今私ApplicationUserStore.FindByNameAsyncを起動します。

これが正しいかどうかは、「正しい」かどうかは分かりません。私は、ASP.NET IDが "任意の"データストア実装で動作することを強く感じているので、IdentityUserを使用するように制約する必要はありません。上記のことは、私が感じている非Entity Frameworkの実装では機能するはずです。