1

メンバーやそのようなものを作成するために独自の「ユーザー」テーブルを使用したいので、カスタム ASP.NET メンバーシップ プロバイダーを構築しています。状況は次のとおりです。

  1. サービス層を含む「サービス」プロジェクトを参照する MVC 4 プロジェクトがあります。
  2. 単体テストに役立つカスタム MembershipProvider のラッパーを作成しました。このラッパーは、カスタム MembershipProvider を参照します。
  3. サービス層からラッパーを参照します。
  4. 私が知る限り、カスタム MembershipProvider を MVC4 プロジェクト内 (App_Data フォルダー内) に配置しました。

これで、MVC4 -> Service Layer -> Wrapper -> MVC4 という循環依存関係ができました。私の質問: どうすればそれを取り除くことができますか? 理想的には、メンバーシップ プロバイダーを別のプロジェクトに配置したいのですが、うまくいきません。それについて何か提案はありますか？Google はあまり役に立ちません。

おまけの質問 1: MembershipProvider の代わりに SqlMembershipProvider を拡張する必要がありますか?

おまけの質問 2: これ以上の選択肢はありませんか? この ASP.NET メンバーシップ全体は本当に時代遅れに感じられ、多くのマイナス面があります (たとえば、テスト可能に構築されていません)。

4

1 に答える 1

2

カスタム メンバーシップ プロバイダーを別のプロジェクトに完全に配置できます。個別の DLL としてビルドしたものが 2 つあり、Web プロジェクトに参照を追加しました。

サービスレイヤーに参照を追加した理由については言及していませんが、これが必要な場合は、実際にはそれらを 2 つの異なるスコープとして扱う必要があるため、2 つの別個のソリューションが必要です。メンバーシップを認証するために WCF サービスを呼び出す必要があるメンバーシップ プロバイダーが 1 つありますが、これらは 2 つの別個の部分であり、2 つの間でコードを共有するべきではありません。

コードを App_Data フォルダーに配置する必要はありません。メンバーシップ プロバイダー プロジェクトまたは DLL への参照を Web サイト プロジェクトに追加するだけです。右

ボーナス質問 1: いいえ。

おまけの質問 2: メンバーシップ プロバイダーは (Microsoft に関する限り) TDD の動き全体よりも前から存在していたので、そうです、彼らはテストを実際に助長するものではありません。ただし、基本クラスから継承する場合は、十分にテストされ、使い古されたフレームワークにフックすることになるため、実際にはカスタム部分をテストするだけで済みます。

于 2012-04-19T00:17:30.640 に答える