リポジトリパターンを使用した.NETメンバーシップ

Question

私のチームは、統合リポジトリ抽象化の背後にさまざまなデータソースを隠すドメインモデルの設計を進めています。このアプローチの主な要因の1つは、これらのデータソースが近い将来大幅に変更される可能性が非常に高いことです。データソースの1つは、元々デフォルトのASP.Netメンバーシッププロバイダーを使用して実装されたメンバーシップデータベースです。メンバーシッププロバイダーはSystem.Web.Security名前空間に関連付けられていますが、さまざまな環境で使用されるため、ドメインモデル層がSystem.Web（またはその他の実装/環境の依存関係）に依存しないことを要求する設計ガイドラインがあります-ウェブサイトがデータベースと直接通信することも望まない。

MembershipProviderアプローチと抽象化されたn層アーキテクチャを調和させるための良いアプローチを検討しています。私の最初の感じは、「DomainMembershipProvider」を作成できるということです。ドメインモデルと対話し、リポジトリを処理し、検証/ビジネスロジックを処理するオブジェクトをモデルに実装します。リポジトリは、（まだ未定の）ORM /データアクセスツールを使用してデータアクセスを実装します。

このアプローチには目立った穴がありますか？MembershipProviderクラスと密接に連携していないので、何かが足りないかもしれません。あるいは、上で説明した要件によりよく役立つと思われるアプローチがありますか？

ご意見やアドバイスを事前に感謝します。

よろしく、 ザック

Answer 1

質問が出されてから6ヶ月が経ちましたが、誰も答えを出せなかったようですので、最終的に選んだ解決策を説明すると思いました。

基本的に、MembershipProviderの実装を使用しないことにしました。代わりに、リポジトリの上にある独自のカスタムメンバーシップサービスを使用します。既存のaspnet_Membershipデータベースを維持して、リポジトリが基本的に組み込みのSQLMembershipProvider機能（少なくとも、必要な側面）を複製することが重要でした-最初はLinq-to-SQL経由でしたが、現在はNHibernateに移行しています。すべてのWebサイトが新しいモデルを使用するようにアップグレードされると、1年程度でメンバーシップデータベースを置き換える計画です。

カスタムメンバシッププロバイダを使用することは可能でしたが、最終的には、カスタム実装を使用する方がよりシンプルで、一貫性があり、メンテナンスしやすいことが明らかになりました。ユーザーがログインしていることを確認し、最初に認証されずにサイトの安全な領域にアクセスしようとするユーザーをリダイレクトするために、組み込みのフォーム認証機能を引き続き使用していますが、プロファイルプロバイダーに関連付けられている機能をオーバーライドしました。

最後に、これに対する私たちの気持ちは、メンバーシッププロバイダーはASP.Net内で強力で使いやすいツールですが、アプリケーションで使用されるより広いアプローチに適合しない場合は、検討する価値があるということです。代替アプローチ。

Answer 2

おもしろい、最終的な解決策を投稿してくれてありがとう。私も同様の状況にありますが、カスタムメンバーシッププロバイダーを作成しています。 System.Web名前空間だけでなくDBにもアクセスする必要があるため、プロバイダーを配置する場所がわかりません。この懸念分離の設計全体に違反するのは1つのクラスのようです。