多くの人が、asp.netライブラリの基本クラスから継承するメンバーシッププロバイダーを作成し、そのプロバイダーをweb.configファイルに登録することについて話している理由がわかりません。これをしなくても欲しいものは何でも手に入れることができるからです。対応するデータベースにユーザーが存在するかどうかを確認し、ユーザーを追加し、呼び出してユーザーを認証すると FormsAuthentication.SetAuthCookie
、すべてが機能する静的クラスを作成しました。簡単に言うと、使用するプロバイダーをweb.configファイルに通知する必要がある理由です。なぜ私たちのプロバイダーはメンバーシッププロバイダーを継承する必要があるのですか?
1 に答える
使用するプロバイダーをweb.configファイルに通知する必要がある理由。
これが、ASP.NETでプロバイダーモデルが機能する方法だからです。カスタムプロバイダーを作成する場合は、web.configに登録する必要があります。また、アプリケーションが使用するデフォルトのプロバイダーを指定する必要があります。同じことがロールプロバイダーにも当てはまります。
私たちのプロバイダーはメンバーシッププロバイダーを継承する必要がありますか?
いいえ、その必要はありません。ユーザーの資格情報の確認や新しいユーザーの作成など、メンバーシッププロバイダーのタスクを実行する完全なカスタムコードを作成できます。
メンバーシッププロバイダーは、ほとんどの開発者が精通しているASP.NETアプリケーションでこれらのタスクを実行するための標準的な方法にすぎません。独自のカスタムコードをロールすることにした場合、新しい開発者がチームに参加する場合、彼はこのすべてのカスタムコードについて学ぶ必要があります。
また、静的クラスを作成したとのことですが。このようなものの静的クラスの欠点は、アプリケーションのさまざまなレイヤーを強力に結合しているため、それらを個別にテストして再利用することが難しいことです。メンバーシッププロバイダーの要点は、それが抽象化であるということです。また、すべての機能が必要ない場合は、カスタムメンバーシッププロバイダーを作成するときにすべてのメソッドをオーバーライドする必要はありません。実際に使用しているもののみ。