私はAsp.Net Identityを初めて使用しますが、この質問が馬鹿げていると思われる場合はご容赦ください。したがって、以下のリンクにあるMicrosoft WebサイトのUserStoreクラスとUserManagerクラスの定義を読むと、両方のクラスがユーザーに関する操作を定義するように見えます(追加、検索、削除、変更など)。それで、私はいつ他のものを使用しますか?:
https://msdn.Microsoft.com/en-us/library/dn315446(v = vs.108).aspxhttps://msdn.Microsoft.com/en-us /library/dn613290(v=vs.108).aspx
そこでは非常に複雑で、もっと簡単だったかもしれません。
UserManger
は...マネージャーです。ストレージ、データベースとは実際には相互作用しません。それがUserStore
が行うことです。
実際、UserManagerには constructor があり、UserStoreが必要です。
ユーザーを管理するために別のオブジェクトを使用する必要があるのはなぜですか?さて、主な理由は、EFを使用せずに独自のユーザーストアを作成することを決定できることです。
独自のストレージプロバイダーを実装しようとすると、事態はより明確になります。私はそれをやったので、コードは github からダウンロードできます。
これは serManager です。あなたが見ることができるようにそこに多くはありません。バリデータを設定するためのほんの数行のコード。
serStore それどころか、かなり大きいです。その例では、いくつかのインターフェイスを実装し、いくつかのメソッドをオーバーライドしました。これは、データベースとのやり取りをカスタマイズしたり、クラスを拡張したりする場合に行うことです。
通常、UserStore
と対話することはなく、実際には非表示です。作成してUserManager
に渡すだけで、...忘れてしまいます。
UserManagerをいつでもカスタマイズして、UserStoreを公開できます。
_public class UserManager : UserManager<User, int>
{
public UserManager(IUserStore<User, int> store): base(store)
{
this.Store = store;
}
public IUserStore<User, int> Store { get; set; }
}
_
そして、おそらく、いくつかの方法をovveride:
_public class UserManager : UserManager<User, int>
{
public UserManager(IUserStore<User, int> store): base(store)
{
this.Store = store;
}
public IUserStore<User, int> Store { get; set; }
public override System.Threading.Tasks.Task<IdentityResult> CreateAsync(User user)
{
return base.CreateAsync(user);
}
}
_
ただし、特殊なカスタマイズを行う必要がない限り、それは無意味です。
マネージャーの代わりにストアを使用してユーザーを作成するとします。次のようなことができます:
_await this.UserManager.Store.CreateAsync(new Custom.Identity.User() { UserName = "LeftyX" });
_
そしてそれは動作するでしょう。
上記のクラスでは、ご覧のとおり、UserManagerでCreateAsync
をオーバーライドしています。
このメソッドはUserStore.CreateAsync()
を呼び出しますが、実際には、ベースメソッドCreateAsyncを呼び出す必要があります。
_public override System.Threading.Tasks.Task<IdentityResult> CreateAsync(User user)
{
return base.CreateAsync(user);
}
_
それを行わずに、たとえば代わりにnullを返す場合、_UserStore.CreateAsync
_は呼び出されず、ユーザーは作成されません。
最後に理にかなっています。
このフレームワークの仕組みを理解する最良の方法は、独自のストレージを使用してソリューションをカスタマイズ/実装し、すべてのクラスが相互作用する方法を確認することです。
サンプル project はデータベースと対話しませんが、jsonストレージを使用します。デバッグは非常に簡単です。それを試してみると、物事はある時点でより明確になります。
私はYouTubeでIdentityチュートリアルを見ていましたが、このスクリーンショットが役立つと思います:
そのため、UserManagerは実際に使用する必要があるクラスですが、データベースにデータを保存および取得する方法がわかりません。データがどこに行き来するのかさえわかりません。
これらについては、UserStoreを使用して、たとえば「UserStoreに今後使用するために保存する必要がある新しいユーザーがいます。どこに保存するのか、どうするのかわかりませんそれ、ただ私のためにそれを保存してください」
次に、UserStoreは、データの保存先などの実際の作業を行いますか?どのデータベース?そしてどうやって?デフォルトではEFとSQL Serverが使用されるため、たとえばMySQLなどの他のデータベースを使用する場合は、別のユーザーストアが必要になります。
これは、SQL Serverでのみ機能するメンバーシップと比較して、Identityに追加された機能の1つです。
同じ概念がRoleManagerとRoleStoreにも当てはまります。
IDは、ASP.NET Identityの2つのプライマリブロックに基づいています。 UserManager<T>
クラスの形式をとる認証マネージャーがあります。 UserStore<T>
のインスタンスであるストアマネージャーもあります。
違い?
UserStore<T>
オブジェクトは、UserStore<T>
IDを識別および認証するために使用される認証マネージャーに挿入されます。 UserManager<T>
参照は、UserStore<T>
IDの認証子として機能します。
重要な詳細
ASP.NET Identityは、最新のOpen Web Interfaceに基づいています。これは、[通常]、Microsoft.Owin.Security
: Linked here で宣言されているIAuthenticationManagerインターフェイス、つまり、UserManager
クラスおよびコントローラーに挿入された認証子、および基本的に認証ステップを含むすべての操作。
以下では:
private async Task SignInAsync(ApplicationUser user, bool isPersistent)
{
var identity = await UserManager.CreateIdentityAsync(user,
DefaultAuthenticationTypes.ApplicationCookie);
AuthenticationManager.SignIn(new AuthenticationProperties() {
IsPersistent = isPersistent }, identity);
}
UserManager
認証マネージャーが、 "UserStore
"アプリケーションユーザーを認証マネージャーのIDと照合するために使用されていることがわかります。 ブログから抜粋したスニペット
結論UserManager
は、本質的にASP.NET Identityのドメインロジックです。 「ログイン」または「識別」の処理に使用するコントローラーは、UserStore
によって渡されます。これは、 MSDN:Userstore が示すように...
IUserStore、IUserLoginStore、IUserClaimStore、およびIUserRoleStoreをサポートするユーザーストアのEntity Framework実装を表します。
UserStore
にIDとして修飾するために必要なすべてのフィールドがあり、UserManager
を認証マネージャーとして修飾し、コンテキストを保存する方法(別名IdentityDbContext
または一部SQLに値を格納する他の方法(使用する場合)、ログインをサポートできるIDシステムがあります。