MVVMViewModelとMVCViewModel
ViewModelは、MVVM（Model-View-ViewModel）とASP.NETMVCの推奨実装の両方で使用される用語です。各パターンが同じ用語を使用していることを考えると、「ViewModel」の調査は混乱を招く可能性があります。
MVCViewModelとMVVMViewModelの主な違いは何ですか？たとえば、コントローラーがないことを考えると、MVVMViewModelの方が豊富だと思います。これは本当ですか？
簡潔に答えるのはかなり難しい質問ですが、私はそれを試みます。 （これらの種類の質問への回答は、依然として開発者の間で議論の対象となっていることに注意してください。）
MVCでは、ViewModelはビューのレンダリングに必要なすべての情報を提供します。含まれるデータは、モデルで定義されたデータを使用して作成されます。ビューはViewModelを読み取り、出力をレンダリングします。ビューからの入力はコントローラーに渡されます。コントローラーはモデルを操作し、適切なViewModelを作成し、これをレンダリングのためにビューに渡します。
MVVMでは、ViewModelはMVCと同じ機能を果たしますが、ビューがモデルを操作できるようにするコマンドを提供することで、MVCコントローラーの一部を置き換えます。 WPFデータバインディングは、ViewModelの変更に応じてビューの更新を管理します（これにより、MVCコントローラーの残りの機能が効果的に置き換えられます）。
UI Design Patterns Bingoをプレイしてからしばらく経ちましたが、これを試してみましょう。
MVVMは、MSが思いついたものです... WPFを最大限に活用するのに役立ちます。ビューの状態と動作を簡単にテスト可能なクラス（プレゼンテーションモデル）に結合し、データバインディングを使用してデータを任意のビューに取り込みます。
この link には、MVVMの進化の概要があります。これをFowlerの " GUI Architectures "シリーズと組み合わせると、あなたは道を進んでいるはずです。
更新： MVC-VM というものがあることを知りませんでした。どうやらASP.NETMVC群衆の発案によるものです。 MVVMに似た外観とサウンド（ASP.NET MVC用に調整されていることを除く）。唯一の違いは、VMとViewの間に1：1のマッピングがあるという制限があることです。1：Nを推測したと思いますが、他のすべては一致します。
これは（方法の）古い質問であることは知っていますが、MVCのコンテキストで「モデルの表示」を使用する例として指摘されています。これは正しくなく、どちらかまたは両方のパターンに慣れていない人が混乱する可能性があると私は主張します。それをしている人は誰でも--stahp。これが理由です（そしてそれは回りくどい方法で元の質問への答えですらあります）。
これが発生する場合の例は、 この質問 にあります。ユーザーは、ASP.NET MVCアプリケーションでINotifyPropertyChangedを実装するビューモデルを使用しようとしているため、デスクトップとステートレスのWebアプリケーションの設計をアーキテクチャの失敗と悲惨な状況でマッシュアップしています。
簡単に言うと、MVCパターンには「ビューモデル」はありません。 はですが、機能的には同等であり、それがコントローラーです。部品とその目的を明確にするために、
MVVM（デスクトップアプリケーション）：
- モデル-ビューモデルとビューモデルの間で渡されるデータを保持する強い型のオブジェクト
- 表示-ユーザーが表示し、ユーザーがシステムと対話するためのUI
- モデルの表示-ユーザーアクションの解釈（ICommandなどによる）、実行、アプリケーションの状態の更新
MVC（Webアプリケーション）：
- モデル-ビューモデルとビューモデルの間で渡されるデータを保持する強い型の*オブジェクト
- View-モデル、コード、HTMLを組み合わせてWebページをレンダリングするUIジェネレーター
- Controller-ユーザーの要求を受け入れ、それらを解釈し、アプリケーションの状態を更新し、ビューを使用してこの状態をHTMLWebページに変換します
モデルは両方のパターンで実質的に同じです。デスクトップモデルは更新イベント通知を実装する場合があり、Webモデルは動的（つまり、強く型付けされていない）である場合があり、両方に検証メソッドまたはメタデータが含まれる場合と含まれない場合があります。
デスクトップのビューは、ユーザーに表示されるものです。 Webでは、ブラウザがクライアント側に表示するためのHTMLを出力するジェネレータです。デスクトップでのユーザーインタラクションを解釈する必要がありますが、クライアント側のJavaScript、ブラウザー、およびサーバーに返送されるリクエストによって処理されるWebでは解釈されます。
View Model/Controllerはほぼ機能的に同等ですが、実装方法と動作方法が大きく異なります。 ビューモデルでは、アプリケーションとのユーザーインタラクションは、ICommands、ルーティングされたイベント、およびその他のメソッドを介してビューモデルに転送されます（多くのMVVMフレームワークはさまざまな方法を提供しますビューモデルをUIおよびアプリケーションの他の部分にフックします）。 コントローラーでは、コントローラーがユーザーに結果を返すために必要なすべての情報を含む要求が送信されます（200 OK要求であると想定）。コントローラーは、HTMLジェネレーター（ビュー）が応答を作成するために必要な状態（モデル）を作成するために必要なすべての作業を実行する必要があります。デザイン的には、コントローラーはビューとモデルの上に配置され、両方を認識して制御しますが、ビューモデルはビューの隣に配置され、モデル（およびその他の情報）をそれらの間で渡します。
一部の人々を本当に混乱させているように見えるのは、MVCアプリケーションに混在させることができるクライアント側のMVVMフレームワークがあるということです。これらはユーザーのブラウザのjavascriptにのみ存在し、サーバー側でフォローしている特定のパターンとは何の関係もありません。クライアント側でMVVMを使用する従来のASP Webサイトを実行できます。クライアント側でMVVMを使用する静的HTMLページを実行できます。これらは別個のものです。
これらのjavascriptMVVMフレームワークは、通常、上記のデスクトップMVVMパターンと同様のパターンに従いますが、HTMLDOMとjavascriptの性質により調和して機能するように調整されています。たとえば、DOMに組み込まれている広範なバインディングシステムはなく、javascriptの型システムは非常に限られているため、テンプレートとモデルのマッチングはWPFの場合とは大きく異なります。また、通常はサーバーから切断されて動作し、対話する必要がある場合は、ページをコントローラーにPOSTするよりもAJAX呼び出しを優先します（AJAX呼び出しは通常ASP.NETのWebAPIコントローラーによって処理されます） MVC）。
したがって、要約すると、MVCには実際にはビューモデルはありません。コントローラーは大まかに同等ですが、ユーザー入力を受け取り、解釈し、結果をユーザーに返す方法が大きく異なります。 「ビューモデル」という用語を使用してMVC内のすべてのものを指すと、混乱を招く可能性があるため、避ける必要があります。パターンの適切な部分には適切な用語を使用してください。それは衒学的に見えるかもしれませんが、それは物事を明確に保ち、両方のパターンに不慣れな人々にとって混乱を少なくするのに役立つはずです。