「SimpleMembership」は、asp.netメンバーシップ/ロール管理の未来であると言われています。MVC4「インターネットアプリケーション」テンプレートは、SimpleMembershipを使用してアカウント管理を実装します。ただし、実装方法では、すべてのアプリケーション層が1にマージされます。
彼らがMVCを使用してアプリを適切に階層化するために行ったすべての作業の後で、DIなし、WebMatrix DLLの使用、およびSoCの完全な欠如を伴う、メンバーシップの「前進」のこの見苦しい実装を取得したことに、ちょっとショックを受けました。特に、SimpleMembershipInitializationのActionFilterAttribute-MVC属性から継承し、EFDBContextを直接呼び出します。
私は怠け者だと気づきましたが、SimpleMembershipを使用して「適切な」テンプレートを作成した人はいますか。つまり、アプリに適切な分離層を設定でき、MVCアプリにEFDBContext参照を設定できません。
SimpleMembershipの強力な概念の1つは、この記事で説明するように、アプリケーションのニーズに合わせてユーザープロファイルをカスタマイズできることです。たとえば、登録プロセスに確認の電子メールを追加すると、ユーザーの電子メールアドレスをユーザープロファイルに保存する必要があります。ASP.NETの以前のメンバーシップ/ロール管理では、これを実装するのは非常に醜く、追加されたプロパティはBLOBに格納されていました。うん！
では、これはSimpleMembershipをn層に対応させるための質問と何の関係があるのでしょうか。テンプレートが生成するものはn層に対応していないことに同意しますが、複雑なほとんどの実際のMVCアプリケーションでは、SimpleMembershipをカスタマイズする必要があるため、とにかくアプリケーション要件に固有の層または層を作成する必要があります。別の言い方をすれば、SimpleMembershipの再利用可能な層を作成することは、最も基本的なMVCアプリでのみ役立ちます。
個人的には、SimpleMembershipに関してインターネットテンプレートによって生成されるものはほとんど常に変更されるという結論に達しました。私が参照した最初の記事が指摘しているように、カスタマイズの最初の部分はSimplemembershipInitialization属性を取り除くことです。これは、開発者がフォーム認証を使用していない場合にSimpleMembershipを初期化するための怠惰な方法です。また、多くの場合、SimpleMembershipで使用されるDBContextを、アプリケーションの残りの部分のDBContextに移動する必要があります。多くの場合、ユーザープロファイルは、アプリケーションドメインの残りの部分と緊密に統合されています。
そして、私たちはSoCとASP.NETのセキュリティをテーマにしているので、ASP.NETはこれがあまり得意ではなかったと私は主張します。フォーム認証の場合、コントローラーでAuthorize属性を使用するか、パラメーターとしての役割を果たすアクションを使用します。これにより、アプリケーション開発者は、アプリケーションドメインを設計する際に、セキュリティ設計について考える必要があります。アプリケーションがどのような役割を事前に持つかを決定する必要があります。これらの属性をすべて調べてそれに応じて更新する必要があるため、後で変更することは禁じられています。リソース名と操作タイプ（例：読み取り、書き込み、実行...）をパラメーターとして受け取るカスタム承認属性の使用を開始しました。次に、役割をデータベース内のリソース/操作にマップして、簡単に変更できるようにします。または、管理者がアプリケーションでの役割の実装方法を変更できるようにすることもできます。Microsoftは同じアプローチを取っています現在、ClaimsPrincipalPermissionAttributeは、 WIFを.NET4.5に組み込んでいます。
2013年3月8日更新
SimpleMembershipをMVCアプリケーションから切り離すSimpleSecurityというオープンソースプロジェクトをCodePlexで作成しました。あなたはここでそれについて読むことができます。開発者はSimpleSecurityを変更したいと思うでしょうが、これはオープンソースなので可能です。これが、再利用可能でより優れたSimpleMembershipに進化できるものであるかどうかを確認します。
受け入れられた答えは正しくありません。つまり、N層ではありません。メンバーシップデータアクセスとビジネスロジックは同じレイヤーで発生しています。コードが別のアセンブリにあるからといって、同じレイヤーにないという意味ではありません。
データアクセス層への何らかの転送メカニズムがなければ、これはN層ではありません。
解決策は、WebMatrix SimpleMembershipProviderクラスを継承してオーバーライドし、そのデータアクセス呼び出しを別のホストで実行できるようにすることです。
dotPeekを使用してSimpleMembershipProviderを確認し、オーバーライドで何をすべきかを理解することをお勧めします。
あなたの質問は、n層アーキテクチャ（@klatzibが指摘しているように、レイヤー間の物理的な分離に関するもの）よりもSoCに関連していると思います。
メンバーシッププロバイダー内のロジックには、アプリケーションまたはクライアント固有のコードが含まれていないため、ビジネスロジックとして分類するべきではないと私は主張します。実際、プロバイダーモデルの考え方は、使用されるコンテキストに関係なく、一般的な契約を履行することです。開発者が犯すよくある間違いMembershipProviderは、上位層に存在するはずのアプリケーション固有のビジネスロジックを拡張してボルトで固定することです。それが別の設計で達成したいことである場合、それは間違ったアプローチです。プロバイダーは.NETFrameworkのプラグインであり、コードから完全に抽象化する必要があります。それらは確かにあなたのアプリケーションドメインを含むべきではなく、あなたがそれらを拡張する必要があることはめったにないはずです。
別の方法であなたの質問に答えるとSimpleMembershipProvider、アプリケーション設計やn層アーキテクチャでSoCを禁止しますか？いいえ、そうではありません。MVC4テンプレートは単純化のために構築されActionFilterていますが、プロバイダーの初期化に使用されるのはメンバーシップ実装の一部ではなく、適切と思われる方法でプロバイダーを自由に初期化できます（DIコンテナーファクトリメソッドからこの呼び出しを行うことをお勧めします） ）。実際SimpleMembershipProvider、EFに直接依存することはまったくないため、WebアプリでEFDbContextへの参照を削除することは可能です。
まさに私が探していたもの（ほぼ）。Kevinのn層ソリューションをDapperORMで動作させることを望んでいたので、エンティティフレームワークに関連付けられていなかったらいいのにと思います:(