2

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

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

このアプローチに明白な穴はありますか？私はMembershipProviderクラスと緊密に連携していないため、何かが欠けている可能性があります。あるいは、上記の要件をより適切に満たすと思われるアプローチはありますか？

よろしくお願いします。

よろしく、ザック

4

2 に答える 2

2

質問が出されてから 6 か月が経過しましたが、誰も答えを提供できなかったようです。最終的に選択した解決策を説明しようと思いました。

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

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

最終的には、メンバーシップ プロバイダーは ASP.Net 内の強力で使いやすいツールですが、アプリケーションで使用されるより広いアプローチに適合しない場合は、別のアプローチを検討する価値があると考えています。

于 2010-04-20T23:01:07.203 に答える
0

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

于 2011-01-20T18:04:08.197 に答える