MVCアーキテクチャのベストプラクティス
私の質問は、MVCアプリケーションの設計方法についてです。たとえば、コントローラーパターンからデータアクセスを分離するためにリポジトリパターンでDIを使用することをお勧めしますが、特にMVCに対してそれを行う方法についてはほとんど言及されていません。たとえば、Repositoryクラスはどこに配置しますか？同様に、モデルは実際のデータアクセステクノロジから比較的分離されている必要があるため、これらは特にモデルに関連しているようには見えません。
2番目の質問は、レイヤーまたは層をどのように構成するかです。ほとんどのサンプルアプリケーション（オタクディナー、ミュージックストアなど）はすべて、通常はL2SまたはEFコードを直接呼び出すコントローラーを備えた単一層の2層アプローチ（テストは含まない）を使用しているようです。
マルチティア/レイヤーアプリケーションを作成する場合、MVCに関してベストプラクティスは何ですか？
DIは、コントローラーファクトリを使用してASP MVCで実行されます。このファクトリは、コントローラーの依存関係を解決するために使用されます。
MvcContribには、そのまま使用できるいくつかのController Facotry実装があります。私は彼らのCastle Windsor実装を使用しており、うまく動作します。また、TestHelperクラスをチェックアウトすることをお勧めします。コントローラーのHTTPContext、セッションなどをモックするための非常に優れた機能がいくつかあります。 MVCContrib
個人的には、使用するリポジトリインスタンスをモデルに与えたいと思っています。モデルはAPIをリポジトリー（CRUD）に公開します。コントローラの特定のモデルへの依存関係は、作成時に生成されます（コンストラクタ）。これは、コントローラファクトリを介して注入されます。これは、IoCコンテナが管理するオブジェクトグラフへのエントリポイントです。
たとえば、Repositoryクラスはどこに配置しますか？
それらはモデルに属しています。それらはアプリケーション内モデルです。
レイヤーを構成するにはどうすればよいですか？多層/レイヤーアプリケーションを作成する場合、MVCに関してベストプラクティスは何ですか？
層は、コードの物理的な分離を表します。レイヤーは論理的な分離を表します。レイヤーは（現在のように）MVCに適しています。ビジネスロジックの量に応じて、コントローラーに配置することも、別のアセンブリに配置して、要求サイクル中にコントローラーで使用することもできます。