ASP.NET MVC - 認証レイヤーはどこに行きますか？

Question

私は、このようなMVCソリューションを3つの「プロジェクト」で設定しています。

ウェブ（MVCプロジェクト、ビュー、コントローラ、のviewmodels）

モデル（ドメインオブジェクト）

永続性（NHibernateはマッピング、SessionFactoryの）

私は、リポジトリの構築を開始する必要があります認証モデルから始める予定でした。基本的には、デフォルトのMVCテンプレートに続いて、IMembershipServiceとIFormsAuthenticationServiceと関連クラス（カスタムコードを使用し、認証プロバイダに組み込まれていない）を使用します。

私の質問は...これはどこに行けばよいですか？私のリポジトリは、私のDomainオブジェクトと私のPersistence Layerの両方にアクセスする必要があります。しかし、私はどんな種類の「カップリング」も悪いデザインであることを読んでいます。だから私はモデル/持続性を参照するリポジトリ/サービスのための第4のプロジェクトを作成することを躊躇しています...しかし、私は実際にそれを論理的に行うための他の方法を見つけることはできません。

Answer 1

これは非常に主観的です。

あなたとあなたのチームにとって意味をなさないことをしてください。

私はそれらを残りのリポジトリと一緒に投げます。私はユーザーがアプリケーションの権利の中心にあることを意味しますか？ユーザーは何かを所有していますか？もしそうなら、彼は根ではありませんか？

Answer 2

リポジトリはドメインの一部です。

アセンブリの参照数を減らしてプロジェクトの数を最小限にする場合は、常に緊張が存在します。つまり、機能をより細かいアセンブリに分割することによって、各アセンブリの参照の依存性を減らすことができます。しかし、プロジェクトを過度に多数のアセンブリに分割すると、管理するための労力が必要になります。

もう1つのポイントは、認証にはいくつかの側面があることです。 1つは、ユーザー、役割、権限などのモデルを管理することです。これはドメインの関心事です。もう1つは実行のコンテキスト（ASP.Netアプリケーション、WinFormsなど）とのインタフェースです。これはインフラストラクチャに関する懸案事項です。結果として、私はMVCプロジェクトやフォーム認証クッキーの設定、現在のスレッドプリンシパルの設定などの機能を実行する小さなサービスになります。

Answer 3

Separated interface patternには、モデルとリポジトリインターフェイスがGUIと実際のリポジトリの実装は別として、別個のアセンブリです。これは、後で実装を切り替えることができ、テストを簡素化できるようにするためです。

私は、リポジトリインタフェースと実際の実装をmvcプロジェクトまたはリポジトリプロジェクトに入れても問題ありません。後でIoCコンテナを使用すると、後から移動するのは簡単です。