私はMVCを始めて約1か月ですが、私が理解していることから、アプリアーキテクチャへのかなり良いアプローチは次のとおりです。
MVC<>サービス<>リポジトリ<>コア
MVC内には、ビューと、コントローラーのviewModelを設定するためのコントローラーがあります。私の質問は、データ転送オブジェクトはどこから来るのかということです。私は単一ページのWebアプリを構築しており、最初からそれを実行しようとしています。
私が行った読みから、ViewModelに渡す前に、DTOを使用してModelオブジェクトを「フラット化」する必要があります。それらは、サービスからコントローラーに渡される「必要なデータのみ」のオブジェクトとして機能しますか？その時点で、viewModelsが構築されますか？もしそうなら、各モデル定義（つまり、セット、カード、ユーザー）がコアレイヤーに対応するDTOクラスを持つべきであるというのは一般的に本当ですか？ここでの説明は素晴らしいでしょう、お時間をいただきありがとうございます！
まず、このフレーズについて：「アプリアーキテクチャへのかなり良いアプローチは...」：すべてのアプリに単一の良いアプローチがあるとは思わないので、常に最も単純なアプローチ（つまり、より少ないアプローチ）を使用したいと思います。レイヤー）手元の問題を解決できる可能性があります。
「サービス」と言うと、一部のドメインサービスクラスではなく、Webサービスのレイヤー全体のように見えます。Asp.Net MVCで見たほとんどの場合、コントローラー自体がサービスの役割を果たすことができるため、さらに別のレイヤーを追加する必要がありません。もちろん例外もありますが、複雑さを増す理由が正当であることを確認してください。
DTOとビューモデルについて：DTOは、あなたが説明したように、オブジェクトモデルをフラット化し、「必要なデータのみ」を返します。DTOはより一般的な用語であり、通常、誰が消費者であるかがわからないWebサービスで使用されます。（Asp.Net MVC）ビューモデルは、「ビューに必要なデータのみ」を返す、より特殊な種類のDTOと考えてください。したがって、サービスの追加レイヤーが必要ない場合は、DTOの追加レイヤーも必要ありません。ビューモデルを使用してドメインクラスを直接フラット化し、コントローラーから返します。
実際、非常に単純なアプリケーションの場合、Models x ViewModelsの分離でさえやり過ぎです。ViewBagを使用して、単一のModelレイヤーを使用して両方の役割を果たすことができます。あなたの要件がわからないので、どちらがあなたに適しているかはわかりません。
最後に、1つのコメント：シングルページアプリケーションを構築する必要がある場合、Asp.NetMVCはその仕事に最適なツールではありません。サーバーと、 BackboneJsやAngularJsなどのクライアントMVCフレームワークでAsp.Net Web Api（サービスのみ、ビューなし）を使用することをお勧めします。