MVCアーキテクチャのベストプラクティス[終了]

私の質問は、MVCアプリケーションの設計方法に関するものです。たとえば、RepositoryパターンでDIを使用してデータアクセスをコントローラーから分離することをお勧めしますが、HOWではMVC専用にこれを行うとはほとんど言われていません。たとえば、Repositoryクラスはどこに配置しますか？モデルは、実際のデータアクセステクノロジーから同様に比較的分離する必要があるため、特にモデルに関連しているようには見えません。

2番目の質問には、レイヤーまたは層の構成方法が含まれます。ほとんどのサンプルアプリケーション（オタクディナー、ミュージックストアなど）はすべて、通常はL2SまたはEFコードを直接呼び出すコントローラーを持つ単一層の2層アプローチ（テストをカウントしない）を使用しているようです。

多層/レイヤーアプリケーションを作成する場合、MVCに関するベストプラクティスは何ですか？

DIは、コントローラーファクトリを使用してASP MVCで実現されます。このファクトリは、コントローラの依存関係を解決するために使用されます。

MvcContribには、すぐに使用できるController Facotry実装がいくつかあります。私は彼らのCastle Windsorの実装を使用していますが、うまく機能しています。TestHelperクラスをチェックアウトすることもお勧めします。コントローラーのHTTPContextやセッションなどをモックするための非常にクールな機能があります 。MVCContrib

個人的には、Modelsに作業用のリポジトリインスタンスを提供するのが好きです。モデルは、APIをリポジトリ（CRUD）に公開します。特定のモデルへのコントローラーの依存関係は、作成時に注入されます（コンストラクター）これは、コントローラーファクトリを介して注入されます。これは、IoCコンテナが管理するオブジェクトグラフへのエントリポイントです。

たとえば、Repositoryクラスはどこに配置しますか？

それらはモデルに属します。それらはアプリケーション内モデルです。

レイヤーをどのように構成しますか？多層/レイヤーアプリケーションを作成する場合、MVCに関するベストプラクティスは何ですか？

層は、コードの物理的な分離を表します。レイヤーは論理的な分離を表します。レイヤーは（現在のとおり）MVCに適しています。ビジネスロジックの量に応じて、コントローラに配置するか、別のアセンブリに配置して、リクエストサイクル中にコントローラで使用できます。