私のコントローラは、要求を適切なサービスに切り替えます。サービスは、様々なリポジトリを呼び出します。リポジトリは、純粋にDataAccessのためにLinq to Sql Entitiesを使用し、次にドメインオブジェクトとしてマッピングして返します。次に、サービスがコントローラに提示する内容を決定し、ビューに表示するためにコントローラに返されるPresentationオブジェクトでDOを置き換えます。ASP.net MVC：このパターンは妥当か概念的に間違っていますか？
私は、オブジェクトの多くを持っているように、それはそうなのでSO Iは、サービス・リポジトリドメインObjects（オブジェクト）のプレゼンテーションが
オブジェクト私はいくつかのデータを渡すが、何もしていない、求めていました。これは合理的なシナリオですか、適切なMVCパターンに従っていないのですか？
はい、あなたは正しい考えを持っています。それはクラスとインターフェイス（ユニットテストと模擬/テストクラスを数えることさえできません）が多いかもしれませんが、まともなサイズのアプリケーションがあれば、とにかくたくさん持っていることを嫌悪します。しかし、それを始めるには、あまり初期の利益をあげないことがたくさんあります。
私はプロジェクトで、サービスによって追加された値なしにリポジトリに渡すだけの基本サービスのサービス実装をスキップしているのを見ました。彼らはコントローラからリポジトリにまっすぐに行き、あまり失うことはないようです。
可能であれば、ツールを使用していくつかのクラスの負担を軽減する他の方法があります。たとえば、AutoMapperのようなプロジェクトは、ドメインオブジェクトを合理化してモデルマッピングを表示するのに役立ちます。
アプリケーションが十分に大きければ、あなたのパターンは理にかなっています。そうでなければ、私は大胆な匂いがする...
自分自身に尋ねる：もしこの層が存在しなかったら、それが本当であるかどうかを知るでしょうか？
しかし、私は後の時間に展開したいと思うかもしれませんし、何ですか？準備するのが最善ではありませんか？ – zsharp
"あなたはそれを必要としないだろう" –
私は非常に似たシナリオを持っていました。当初、私のプロジェクトにはUI、コントローラ、サービスレイヤ、リポジトリがありました。私の単体テストはサービスレイヤとリポジトリ（フィルタ）の両方をカバーしており、場合によってはユニットテストも同じことをしていました（サービスレイヤが時々リポジトリにパススルーされる）。
大きなリファクタのために、私はサービスレイヤーを切り離しました。これは、コントローラがリポジトリを直接扱い、フィルタを適用して私が望むものを正確に得ることができるようになりました。
Linq2Sqlオブジェクトをシリアル化できないため、これらのオブジェクトをプレゼンテーションオブジェクトに変換しなければならない場合がありました。
私は怠け者になった時、単純な行動のためにリポジトリに直接行きたいと思って時間を無駄にしている。だから私だけではないと思う？ – zsharp
確かにあなただけではありません。私はサービスを通して厳密なアクセスを始めましたが、シンサービスをスキップするように移動しました。彼らは何も追加していないのであれば、後で簡単に追加することができます。余分な機能が必要な場合は、すぐにリポジトリの周りにサービスを作成しようとしています。 –