IUserStore <TUser> .CreateAsync：カスタム実装の失敗を示す方法？

Question

私はIUserStoreのカスタム実装を書いています。作成メソッドのシグネチャは、次のとおり

public async virtual Task CreateAsync(TUser user) 

そして、それはMicrosoft.AspNet.IdentityコアインタフェースIUserStoreを考慮して理にかなっている（同じである）です。

Microsoft.AspNet.Identityで定義されたUserManagerクラスのインタフェースであるしかし：

public virtual Task<IdentityResult> CreateAsync(TUser user); 

私の問題は、私は私は戻り値の型以降のUserManagerにこのIdentityResultを渡す必要があるかを確認していないですストアは単純に "タスク"です。ユーザーを作成できるかどうかを判断するカスタムロジックがあるため、CreateAsyncの結果をUserManagerに伝える必要があります。

Answer 1

あなたがIUserStore.CreateAsyncを呼び出すことが前に見ることができます（これは、Identity 2.0用です）source code for UserManager.CreateAsyncを見ると、それは実際に関連するIdentityResultオブジェクトを返す責任があるIIdentityValidator<TUser>.ValidateAsyncに呼び出し、作る：

public virtual async Task<IdentityResult> CreateAsync(TUser user) 
{ 
     ThrowIfDisposed(); 
     await UpdateSecurityStampInternal(user).ConfigureAwait(false); 
     var result = await UserValidator.ValidateAsync(user).ConfigureAwait(false); 
     if (!result.Succeeded) 
     { 
      return result; 
     } 
     if (UserLockoutEnabledByDefault && SupportsUserLockout) 
     { 
      await GetUserLockoutStore().SetLockoutEnabledAsync(user, true).ConfigureAwait(false); 
     } 
     await Store.CreateAsync(user).ConfigureAwait(false); 
     return IdentityResult.Success; 
} 

IUserStore.CreateAsyncの主な目的は、データを保存する基になるデータソースを呼び出すことです。実際にIIdentityValidator<TUser>を実装して、UserManagerインスタンスに設定したいと思うようです。ユーザーが作成することがカントのアプリケーション・フローでは、

Answer 2

答えはここに、in the source codeある記事の執筆時点でのUserManagerでの実装の一部です：

public virtual async Task<IdentityResult> CreateAsync(TUser user, 
     CancellationToken cancellationToken = default(CancellationToken)) 
    { 
     ThrowIfDisposed(); 
     await UpdateSecurityStampInternal(user, cancellationToken); 
     var result = await ValidateUserInternal(user, cancellationToken); 
     if (!result.Succeeded) 
     { 
      return result; 
     } 
     if (Options.Lockout.EnabledByDefault && SupportsUserLockout) 
     { 
      await GetUserLockoutStore().SetLockoutEnabledAsync(user, true, cancellationToken); 
     } 
     await UpdateNormalizedUserNameAsync(user, cancellationToken); 
     await Store.CreateAsync(user, cancellationToken); 
     return IdentityResult.Success; 
    } 

だから、基本的に、彼らは常にtrueを返します。これは、現在のバージョンでは、私の作成チェックをUserStoreに置くことは、フレームワークの意図された使い方に反することを意味します。

しかし、私はこれが次のリリースで変更されることに気付きました。 IUserStoreインターフェースはなります：

Task<IdentityResult> CreateAsync(TUser user, CancellationToken cancellationToken); 

とのUserManager実装：

public virtual async Task<IdentityResult> CreateAsync(TUser user) 
    { 
     ThrowIfDisposed(); 
     await UpdateSecurityStampInternal(user); 
     var result = await ValidateUserInternal(user); 
     if (!result.Succeeded) 
     { 
      return result; 
     } 
     if (Options.Lockout.AllowedForNewUsers && SupportsUserLockout) 
     { 
      await GetUserLockoutStore().SetLockoutEnabledAsync(user, true, CancellationToken); 
     } 
     await UpdateNormalizedUserNameAsync(user); 
     await UpdateNormalizedEmailAsync(user); 

     return await Store.CreateAsync(user, CancellationToken); 
    } 

だからUSERSTOREで作成ロジックは、その時点で可能になります置きます。これはクライアントが完全性の懸念を処理する必要がないので、私の意見ではより良い設計となるでしょう。