MVCとMVVMの違いは何ですか？[閉まっている]

標準の「Model View Controller」パターンとMicrosoftのModel / View / ViewModelパターンに違いはありますか？

MVC / MVVMはどちらか一方の選択ではありません。

ASP.NetとSilverlight / WPF開発の両方で、2つのパターンが異なる方法で出現します。

ASP.Netの場合、MVVMはビュー内の双方向バインドデータに使用されます。これは通常、クライアント側の実装です（例：Knockout.jsを使用）。一方、MVC はサーバー側の懸念を分離する方法です。

SilverlightとWPFの場合、MVVMパターンはより包括的であり、MVC（またはソフトウェアを個別の責任に整理する他のパターン）の代わりとして機能するように見えます。頻繁にこのパターンで出てきた一つの前提は、ということでしたViewModel単純でコントローラを置き換えるMVC（あなただけ置き換えることができているかのようVMのためのC頭字語で、すべてが赦されるだろう）...

ViewModelは、個別のコントローラーの必要性を必ずしも置き換えるものではありません。

問題がある：それは、独立してテスト可能*、特に再利用可能な必要なときに、ビュー・モデルは、それを表示しているものを眺めないアイデアを持っていませんが、もっと重要なことにそのデータから来ていないという考え。

*注意：実際には、コントローラーは、ViewModelからユニットテストを必要とするほとんどのロジックを削除します。その後、VMは、ほとんどテストを必要としないダムコンテナーになります。VMはデザイナーとコーダーの間の単なる橋渡しであるため、これは良いことであり、シンプルに保つ必要があります。

MVVMであっても、コントローラーには通常、すべての処理ロジックが含まれ、どのビューモデルを使用してどのビューにどのデータを表示するかを決定します。

これまでのところ、ViewModelパターンの主な利点は、XAMLコードビハインドからコードを削除して、XAML編集をより独立したタスクにすることです。必要に応じて、アプリケーションの全体的なロジックを制御するためのコントローラーを作成します（しゃれたことはありません）。

私たちが従う基本的なMVCVMガイドラインは次のとおりです。

• ビューには、特定の形のデータが表示されます。データの出所はわかりません。
• ViewModel は特定の形状のデータとコマンドを保持しますが、データまたはコードがどこから来たか、またはどのように表示されるかはわかりません。
• モデルは実際のデータ（さまざまなコンテキスト、ストア、またはその他のメソッド）を保持します
• コントローラーはイベントをリッスンして公開します。コントローラーは、表示されるデータと場所を制御するロジックを提供します。コントローラは、ViewModelが実際に再利用できるように、ViewModelにコマンドコードを提供します。

また、Sculptureのコード生成フレームワークは、MVVMとPrismに類似したパターンを実装しており、コントローラーを広範囲に使用して、すべてのユースケースロジックを分離しています。

コントローラがビューモデルによって時代遅れになっていると思い込まないでください。

このトピックに関するブログを始めました。できる限り追加します。ほとんどのナビゲーションシステムはビューとVMを使用するだけなので、MVCVMと一般的なナビゲーションシステムの組み合わせには問題がありますが、これについては後の記事で説明します。

MVCVMモデルを使用するもう1つの利点は、アプリケーションの存続期間中、メモリに存在する必要があるのはコントローラオブジェクトだけであり、コントローラには主にコードとほとんど状態データ（小さなメモリオーバーヘッド）が含まれないことです。これにより、ビューモデルを保持する必要があるソリューションよりもメモリ消費量の少ないアプリとなり、特定のタイプのモバイル開発（Silverlight / Prism / MEFを使用するWindows Mobileなど）に最適です。もちろん、応答性のために時々キャッシュされたVMを保持する必要がある場合があるため、これはアプリケーションのタイプに依存します。

注：この投稿は何度も編集されており、具体的に尋ねられた狭い質問を対象としていなかったため、最初の部分も更新して、それについても説明します。以下のコメントでの議論の多くはASP.Netにのみ関連し、全体像には関係しません。この投稿は、Silverlight、WPF、およびASP.NetでのMVVMの幅広い使用法をカバーし、コントローラーをViewModelsで置き換えることを阻止することを目的としています。

これらの頭字語が何を意味するのかを理解する最も簡単な方法は、それらを一瞬忘れることです。代わりに、元のソフトウェアについて、それぞれについて考えてください。結局のところ、初期のWebとデスクトップの違いだけです。

2000年代半ばに複雑さが増すにつれて、1970年代に初めて説明されたMVCソフトウェア設計パターンがWebアプリケーションに適用され始めました。データベース、HTMLページ、およびその間のコードについて考えてください。MVCに到達するためにこれを少し調整してみましょう：»database«の場合、データベースとインターフェイスコードを想定します。»HTMLページ«の場合、HTMLテンプレートとテンプレート処理コードを想定します。「コードの中間」について、ユーザーのクリックをアクションにマッピングし、おそらくデータベースに影響を与え、別のビューが表示されると仮定しましょう。少なくとも、この比較の目的はそれだけです。

このWeb機能の1つの機能を保持してみましょう。現在ではありませんが、JavaScriptが卑劣で卑劣なものであった10年前に存在していたため、実際のプログラマーはこれを避けてうまくやっていました。HTMLページは基本的にばかで受動的です。ブラウザはシンクライアントですが、使用する場合は貧弱なクライアントです。ブラウザーにはインテリジェンスはありません。全ページがルールをリロードします。»view«は毎回新しく生成されます。

このWebの方法は、大流行しているにもかかわらず、デスクトップに比べてひどく逆転したことを覚えておいてください。デスクトップアプリは、ファットクライアント、つまりリッチクライアントです。（Microsoft Wordのようなプログラムでさえ、ある種のクライアント、つまりドキュメントのクライアントと考えることができます。）それらは、データに精通し、知識に満ちたクライアントです。彼らはステートフルです。処理しているデータをメモリにキャッシュします。完全なページのリロードのようながらくたはありません。

そして、このリッチなデスクトップの方法は、おそらく2番目の頭字語、MVVMが生まれた場所です。Cの省略によって、文字にだまされないでください。コントローラはまだそこにあります。彼らはする必要があります。何も削除されません。ステートフルネス、クライアントにキャッシュされたデータ（およびそれとともに、そのデータを処理するためのインテリジェンス）を1つ追加するだけです。そのデータ、本質的にはクライアントのキャッシュは、「ViewModel」と呼ばれるようになります。それが豊かな双方向性を可能にするものです。以上です。

• MVC =モデル、コントローラー、ビュー=基本的に一方向の通信=低い対話性
• MVVM =モデル、コントローラー、キャッシュ、ビュー=双方向通信=豊富な対話性

Flash、Silverlight、そして最も重要なこととしてJavaScriptを使用すると、WebがMVVMを採用したことがわかります。ブラウザは、正当にシンクライアントと呼ばれることはありません。彼らのプログラマビリティを見てください。彼らのメモリ消費量を見てください。最新のWebページ上のすべてのJavascript対話機能を見てください。

個人的には、この理論と頭字語のビジネスは、具体的な現実でそれが何を指しているのかを見ると理解しやすいと思います。抽象的概念は、特に具体的な問題で示される場合に役立つので、理解が一巡する可能性があります。

MVVM Model-View ViewModelはMVC、Model-View Controllerに似ています

コントローラはViewModelに置き換えられます。ViewModelはUIレイヤーの下にあります。ViewModelは、ビューが必要とするデータおよびコマンドオブジェクトを公開します。これは、ビューがデータとアクションを取得するコンテナオブジェクトと考えることができます。ViewModelはモデルからデータを引き出します。

Russel EastがブログでMVVMがMVCと異なるのはなぜかを詳しく説明しています

1つには、MVVMは、XAMLを使用して表示を処理するMVCパターンの進歩です。 この記事では、2つの側面のいくつかについて概説します。

モデル/ビュー/ビューモデルアーキテクチャの主な目的は、データ（「モデル」）の上に、データの概念をより密接にマップする非ビジュアルコンポーネントの別のレイヤー（「ビューモデル」）があることです。データのビュー（「ビュー」）の概念について説明します。モデルが直接ではなく、ビューがバインドするのはビューモデルです。

Microsoftは、ここでWindows環境のMVVMパターンの説明を提供しています。

ここに重要なセクションがあります：

Model-View-ViewModelデザインパターンでは、アプリは3つの一般的なコンポーネントで構成されます。

• モデル：これは、アプリが使用するデータモデルを表します。たとえば、画像共有アプリでは、このレイヤーは、デバイスで利用可能な画像のセットと、画像ライブラリの読み取りと書き込みに使用されるAPIを表す場合があります。

• 表示：アプリは通常、UIの複数のページで構成されます。ユーザーに表示される各ページは、MVVM用語でのビューです。ビューは、ユーザーに表示されるものを定義およびスタイルするために使用されるXAMLコードです。モデルからのデータはユーザーに表示され、アプリの現在の状態に基づいてこのデータをUIに提供するのはViewModelの役割です。たとえば、写真共有アプリでは、ビューは、デバイス上のアルバムのリスト、アルバム内の写真、およびおそらくユーザーに特定の写真を表示する別のUIになります。

• ViewModel：ViewModelは、データモデル、または単にモデルを、アプリのUIまたはビューに関連付けます。これには、モデルからのデータを管理するためのロジックが含まれており、XAML UIまたはビューがバインドできるプロパティのセットとしてデータを公開します。たとえば、画像共有アプリでは、ViewModelはアルバムのリストを公開し、アルバムごとに画像のリストを公開します。UIは、画像の取得元と取得方法に依存しません。これは、ViewModelによって公開された一連の画像を単に認識し、ユーザーに表示します。

主な違いの1つは、MVCではVがMを直接読み取り、Cを介してデータを操作することですが、MVVMでは、VMはMプロキシとして機能し、利用可能な機能を提供します。 V.

私ががらくたに満ちていなければ、VMが単なるMプロキシであり、Cがすべての機能を提供するハイブリッドを誰も作成していないことに驚いています。

MVCは制御された環境であり、MVVMは反応的な環境です。

制御された環境では、コードが少なく、ロジックの共通ソースが必要です。これは常にコントローラー内に存在する必要があります。しかしながら; Webの世界では、MVCはビュー作成ロジックとビュー動的ロジックに簡単に分割されます。作成はサーバー上にあり、動的はクライアント上にあります。これは、AngularJSと組み合わせたASP.NET MVCでよく見られますが、サーバーはビューを作成してモデルを渡し、クライアントに送信します。その後、クライアントはビューと対話し、その場合はAngularJSがローカルコントローラーとしてステップインします。モデルまたは新しいモデルが送信されると、サーバーコントローラーに戻されて処理されます。（したがって、このサイクルは継続し、ソケットやAJAXなどで作業する場合、この処理の他の多くの変換がありますが、すべてのアーキテクチャで同じです。）

MVVMは事後対応環境であり、通常、何らかのイベントに基づいてアクティブになるコード（トリガーなど）を記述します。XAMLでは、MVVMが繁栄しますが、これはすべて組み込みのデータバインディングフレームワークで簡単に実行できますが、前述のように、これは任意のプログラミング言語を使用する任意のビューの任意のシステムで機能します。MS固有ではありません。ViewModelが起動し（通常はプロパティ変更イベント）、Viewは作成したトリガーに基づいてそれに応答します。これは技術的になる可能性がありますが、最終的にはビューにはステートレスでロジックがありません。単に値に基づいて状態を変更します。さらに、ViewModelはステートレスであり、ロジックはほとんどありません。モデルは状態を維持するだけなので、ロジックは本質的にゼロの状態です。これをアプリケーションの状態（モデル）、状態トランスレータ（ViewModel）、そして視覚的な状態/相互作用（ビュー）として説明します。

MVCデスクトップまたはクライアント側アプリケーションでは、モデルが必要であり、モデルはコントローラーによって使用される必要があります。モデルに基づいて、コントローラーはビューを変更します。ビューは通常、インターフェースを備えたコントローラーに関連付けられているため、コントローラーはさまざまなビューを操作できます。ASP.NETでは、コントローラーがモデルを管理し、選択したビューにモデルを渡すため、MVCのロジックはサーバー上で少し後方にあります。ビューはモデルに基づくデータで満たされ、独自のロジック（通常はAngularJSで実行されるような別のMVCセット）を持ちます。人々はこれを主張してこれをアプリケーションMVCと混同し、両方を実行しようとしますが、その時点でプロジェクトの維持は最終的には惨事になります。MVCを使用する場合、常にロジックと制御を1つの場所に配置します。コントローラーまたはモデルデータに対応するために、ビューの背後のコード（またはWebのJS経由のビュー）にビューロジックを記述しないでください。コントローラにビューを変更させます。ビューに存在する必要がある唯一のロジックは、それが使用しているインターフェイスを介して作成および実行するために必要なものです。この例として、ユーザー名とパスワードの送信があります。デスクトップまたはWebページ（クライアント上）のどちらであるかは、ビューが送信アクションを起動するたびにコントローラーが送信プロセスを処理する必要があります。正しく実行すれば、MVC Webまたはローカルアプリを簡単に見つけることができます。デスクトップまたはWebページ（クライアント上）のどちらであるかは、ビューが送信アクションを起動するたびにコントローラーが送信プロセスを処理する必要があります。正しく実行すれば、MVC Webまたはローカルアプリを簡単に見つけることができます。デスクトップまたはWebページ（クライアント上）のどちらであるかは、ビューが送信アクションを起動するたびにコントローラーが送信プロセスを処理する必要があります。正しく実行すれば、MVC Webまたはローカルアプリを簡単に見つけることができます。

MVVMは完全にリアクティブなので、個人的には私のお気に入りです。モデルが状態を変更する場合、ViewModelはその状態をリッスンして変換し、それだけです!!! その後、ビューは状態の変更についてViewModelをリッスンし、ViewModelからの変換に基づいて更新します。一部の人々はそれを純粋なMVVMと呼んでいますが、実際には1つしかなく、どのようにそれを主張するかは気にせず、常に純粋なMVVMであり、ビューにはまったくロジックが含まれていません。

少し例を示します。ボタンを押すとメニューがスライドインしたいとします。MVCでは、インターフェイスにMenuPressedアクションがあります。コントローラーは、メニューボタンをクリックしたときにそれを認識し、SlideMenuInなどの別のインターフェイスメソッドに基づいて、ビューをメニュー内でスライドするように指示します。往復の理由は？コントローラがあなたができないか、代わりに何か他のことをしたいと決めた場合、それが理由です。コントローラーはビューを担当する必要があります。コントローラーは、コントローラーからの指示がない限り、ビューは何も実行しません。しかしながら; MVVMでは、アニメーションのスライドメニューは組み込みで一般的である必要があり、スライドインするように指示される代わりに、何らかの値に基づいてスライドメニューが実行されます。したがって、ViewModelをリッスンし、ViewModelが言うと、IsMenuActive = true（または）アニメーションが行われます。さて、それで私は別のポイントを作りたいと本当に言いました、そして注意してください。IsMenuActiveは、おそらく悪いMVVMまたはViewModelデザインです。ViewModelを設計するときは、Viewに機能がないことを前提として、変換されたモデルの状態を渡すだけにしてください。このようにして、ビューを変更してメニューを削除し、データ/オプションを別の方法で表示する場合、ViewModelは関係ありません。では、メニューをどのように管理しますか？データが理にかなっている場合は、そのようにしてください。したがって、これを行う1つの方法は、メニューにオプションのリスト（おそらく内部のViewModelの配列）を与えることです。そのリストにデータがある場合、メニューはトリガーを介して開くことを認識し、そうでない場合はトリガーを介して非表示にすることを認識します。ViewModelにメニューのデータがあるかどうかだけです。ViewModelでそのデータを表示/非表示にすることはしないでください。単にモデルの状態を変換します。このように、ビューは完全にリアクティブで汎用的であり、さまざまな状況で使用できます。

これらのすべては、それぞれのアーキテクチャに少なくとも少しでも精通していない場合はまったく意味を成さず、ネット上にALOT OF BAD情報が見つかると非常に混乱する可能性があります。

だから...これを正しくするために心に留めておくべきこと。アプリケーションの設計方法とSTICK TO ITを事前に決定します。

素晴らしいMVCを行う場合は、コントローラーが管理可能で、ビューを完全に制御できることを確認してください。大きなビューがある場合は、異なるコントローラーを持つビューにコントロールを追加することを検討してください。それらのコントローラーを別のコントローラーにカスケード接続しないでください。維持するのは非常にイライラします。少し時間を取って、個別のコンポーネントとして機能するように個別に設計してください...そして、常にコントローラーにモデルにストレージのコミットまたは永続化を指示させます。でのMVCの理想的な依存関係のセットアップは、ビュー←コントローラー→モデル またはASP.NETを使用することです（開始しないでください）モデル←ビュー↔コントローラー→モデル（モデルは、コントローラーからビューへと同じまたはまったく異なるモデルにすることができます）...もちろん、この時点でビュー内のコントローラーを知る必要があるのは、ほとんどの場合、エンドポイント参照がモデルを渡す場所を知るためです。

あなたがMVVMをするなら、私はあなたの親切な魂を祝福しますが、時間をかけて正しいことをしてください！インターフェースを使用しないでください。ビューに、値に基づいてどのように表示するかを決定させます。モックデータ付きビューで遊んでください。あなたがその時にそれを望んでいなかったとしても、（例のように）あなたにメニューを表示しているビューを持っているなら、それは良いです。あなたが見ているように動作し、必要に応じて値に基づいて反応しています。トリガーにさらにいくつかの要件を追加して、ViewModelが特定の変換された状態にあるときにこれが起こらないようにするか、ViewModelにこの状態を空にするように命令します。ViewModelでこれを削除しないでください。内部ロジックを使用して、ビューから表示するかどうかをそこから決定する場合と同じようにしてください。ViewModelにメニューがあるかどうかは想定できないことに注意してください。そして最後に、モデルは、状態を変更し、最も可能性が高いストアを行えるようにする必要があります。ここで検証が行われ、すべてが行われます。たとえば、モデルが状態を変更できない場合は、ダーティまたは何かとして自身にフラグを立てます。ViewModelがこれを認識すると、ダーティなものを変換し、Viewはこれを認識して、別のトリガーを介していくつかの情報を表示します。ビュー内のすべてのデータはViewModelにバインドできるため、すべてを動的にできるのはModelだけであり、ViewModelはViewがバインドにどのように反応するかまったくわかりません。実際のところ、モデルにはViewModelの概念もありません。依存関係を設定するとき、それらはそのように指し、そうでなければならない t状態を変更すると、ダーティまたは何かのフラグが立てられます。ViewModelがこれを認識すると、ダーティなものを変換し、Viewはこれを認識して、別のトリガーを介していくつかの情報を表示します。ビュー内のすべてのデータはViewModelにバインドできるため、すべてを動的にできるのはModelだけであり、ViewModelはViewがバインドにどのように反応するかまったくわかりません。実際のところ、モデルにはViewModelの概念もありません。依存関係を設定するとき、それらはそのように指し、そうでなければならない t状態を変更すると、ダーティまたは何かのフラグが立てられます。ViewModelがこれを認識すると、ダーティなものを変換し、Viewはこれを認識して、別のトリガーを介していくつかの情報を表示します。ビュー内のすべてのデータはViewModelにバインドできるため、すべてを動的にできるのはModelだけであり、ViewModelはViewがバインドにどのように反応するかまったくわかりません。実際のところ、モデルにはViewModelの概念もありません。依存関係を設定するとき、それらはそのように指し、そうでなければならない ビュー内のすべてのデータはViewModelにバインドできるため、すべてを動的にできるのはModelだけであり、ViewModelはViewがバインドにどのように反応するかまったくわかりません。実際のところ、モデルにはViewModelの概念もありません。依存関係を設定するとき、それらはそのように指し、そうでなければならない ビュー内のすべてのデータはViewModelにバインドできるため、すべてを動的にできるのはModelだけであり、ViewModelはViewがバインドにどのように反応するかまったくわかりません。実際のところ、モデルにはViewModelの概念もありません。依存関係を設定するとき、それらはそのように指し、そうでなければならないビュー→ビューモデル→モデル （およびここでの補足説明...そしておそらくこれも議論されるでしょうが、私は気にしません...そのモデルが不変でない限り、モデルをビューに渡さないでください。それ以外の場合は、適切なViewModel。ビューはモデル期間を表示するべきではありません。私は、あなたが見たデモやそれをどのように実行したかをラットにクラックさせます。それは間違っています。）

これが私の最後のヒントです...うまく設計された、しかし非常にシンプルなMVCアプリケーションを見て、MVVMアプリケーションでも同じようにしてください。1つは柔軟性がゼロに制限されたより多くの制御を備え、もう1つは制御がなく制限のない柔軟性を備えます。

制御された環境は、一連のコントローラまたは（単一のソース）からアプリケーション全体を管理するのに適していますが、リアクティブ環境は、アプリケーションの残りの部分がまったく何であるかまったくわからなくても、別々のリポジトリに分割できます。マイクロ管理vs無料管理。

私が十分に混乱していない場合は、私に連絡してみてください...イラストと例を挙げて、これについて詳しく説明してもかまいません。

結局のところ、私たちはすべてプログラマーであり、コーディングの際に無政府状態が私たちの中に住んでいます...そのため、ルールが破られ、理論が変化し、これらすべてが最終的に独り占めされることになります...プロジェクトや大規模なチームでは、設計パターンに同意してそれを実施することが本当に役立ちます。ある日、それは最初に取られた小さな追加のステップを、節約の飛躍的かつ限界的なものにするでしょう。

単純な違い：（YaakovのCoursera AngularJSコースに触発された）

MVC（Model View Controller）

1. モデル：モデルにはデータ情報が含まれます。ControllerおよびViewを呼び出したり使用したりしません。ビジネスロジックとデータを表す方法が含まれています。このデータの一部は、何らかの形でビューに表示される場合があります。また、あるソースからデータを取得するロジックを含めることもできます。
2. コントローラ：ビューとモデル間の接続として機能します。ビューはコントローラーを呼び出し、コントローラーはモデルを呼び出します。基本的には、モデルやビューに適宜変更を通知します。
3. 表示： UIパーツを扱います。ユーザーと対話します。

MVVM（モデルビューモデル）

ViewModel：

1. これは、ビューの状態の表現です。
2. ビューに表示されるデータを保持します。
3. 表示ロジックとも呼ばれるビューイベントに応答します。
4. ビジネスロジック処理のために他の機能を呼び出します。
5. 何かを表示するようにビューに直接要求しないでください。

MVVMは、プレゼンテーションモデルパターンの改良版（議論可能）です。唯一の違いはWPFがデータバインディングとコマンド処理を行う機能を提供する方法にあるためです。

viewmodelは、ユーザーインターフェイス要素の「抽象」モデルです。それはあなたが非視覚的な方法で（例えばそれをテストするために）あなたのビューでコマンドとアクションを実行できるようにしなければなりません。

MVCを使用したことがある場合は、モデルオブジェクトを作成してビューの状態を反映させると便利なことがあります。たとえば、編集ダイアログの表示と非表示を切り替える場合などです。その場合は、ビューモデルを使用しています。

MVVMパターンは、そのプラクティスをすべてのUI要素に単純化したものです。

また、これはMicrosoftのパターンではありません。追加されるのは、WPF / Silverlightデータバインディングがこのパターンでの作業に特に適していることです。しかし、Javaサーバーのフェイスなどでそれを使用することを妨げるものは何もありません。

他の答えは、建築パターンの主題にあまり詳しくない人には理解しにくいかもしれません。アプリアーキテクチャに不慣れな人は、その選択が実際にアプリにどのように影響するか、コミュニティでの大騒ぎについて知りたいと思うかもしれません。

上記に光を当てようとして、MVVM、MVP、MVCを含むこの脚本を作りました。ストーリーは、ユーザーが映画検索アプリの「検索」ボタンをクリックすることから始まります…：

ユーザー：…をクリックします

表示：それは誰ですか？[ MVVM | MVP | MVC ]

ユーザー：検索ボタンをクリックしただけで…

表示：わかりました、しばらくお待ちください... [ MVVM | MVP | MVC ]

（ViewがViewModelを呼び出す| Presenter | Controller …）[ MVVM | MVP | MVC ]

表示：ちょっとViewModel | プレゼンター | コントローラー、ユーザーが検索ボタンをクリックしただけですが、どうすればよいですか？[ MVVM | MVP | MVC ]

ViewModel | プレゼンター | コントローラー：ねViewビュー、そのページに検索用語はありますか？[ MVVM | MVP | MVC ]

表示：はい、…ここに…「ピアノ」[ MVVM | MVP | MVC ]

-これは、MVVMとMVPの最も重要な違いです。MVC ———

プレゼンター：おかげビュー、...一方私は、上の検索用語まで探していモデルを、[彼/彼女のプログレスバーを表示してくださいMVPを | MVC ]

（プレゼンター | コントローラーがモデルを呼び出しています…）[ MVP | MVC ]

ViewController：おかげで、モデルで検索語句を検索しますが、直接更新しません。代わりに、結果がある場合はsearchResultsListObservableへのイベントをトリガーします。だからあなたはそれについて観察したほうがいい。【MVVM】

（searchResultsListObservableのトリガーを監視している間、ViewModelはユーザーに話しかけないため、ビューはユーザーに進行状況バーを表示する必要があると考えます）

——————————————————————————————

ViewModel | プレゼンター | コントローラー：ねModelモデル、この検索用語に一致するものはありますか？：「ピアノ」[ MVVM | MVP | MVC ]

モデル：ちょっとViewModel | プレゼンター | コントローラ、チェックさせて…[ MVVM | MVP | MVC ]

（モデルは映画データベースにクエリを作成しています…）[ MVVM | MVP | MVC ]

（ しばらくして … ）

————これは、MVVM、MVP、MVCの分岐点です ————–

モデル：ViewModelのリストを見つけました| プレゼンター、ここではJSON "[{" name "：" Piano Teacher "、" year "：2001}、{" name "：" Piano "、" year "：1993}]"で記述されています [ MVVM | MVP ]

モデル：利用可能な結果がいくつかあります、コントローラー。インスタンスにフィールド変数を作成し、結果を入力しました。名前は“ searchResultsList” [ MVC ]です。

（プレゼンター | コントローラのおかげでモデルとに戻って取得するビュー）[ MVP | MVC ]

プレゼンター：Viewを待っていただきありがとうございます。一致する結果のリストを見つけて、表示可能な形式[[Piano Teacher 2001]、[Piano 1993]]で整理しました。また、進行状況バーを非表示にしてください[ MVP ]

Controller：Viewを待ってくれてありがとう、私はModelに検索クエリについて尋ねました。一致する結果のリストが見つかり、インスタンス内の「searchResultsList」という名前の変数に保存されたと述べています。そこから入手できます。また、進行状況バーを非表示にしてください[ MVC ]

ViewModel：searchResultsListObservableのすべてのオブザーバーに、この新しいリストが表示可能な形式であることが通知されます：[“ Piano Teacher 2001”、” Piano 1993”]。[ MVVM ]

表示：ありがとうございましたプレゼンター[ MVP ]

表示：ありがとう「コントローラー」[ MVC ]（ビューが疑問を投げかけています。モデルから得た結果をユーザーにどのように提示すればよいですか？映画の制作年を最初にするか、最後にするか...？）

表示：ああ、searchResultsListObservableに新しいトリガーがあります…いいですね、プレゼン可能なリストがあります。リストに表示するだけです。結果が表示されたので、進行状況バーも非表示にする必要があります。【MVVM】

興味がある場合は、こちらに一連の記事を書いて、MVVM、MVP、MVCを映画検索Androidアプリを実装して比較しています。

MVCを使用して厳密に型指定されたViewModelをビューに挿入する

1. コントローラは、ViewModelを更新し、それをViewに挿入する役割を果たします。（取得リクエストの場合）
2. ViewModelは、DataContextおよび最後に選択されたアイテムなどのビューステートのコンテナです。
3. モデルはDBエンティティを含み、クエリとフィルタリングを行うDBスキーマに非常に近いです。（私はこれのためにEFとLINQが好きです）
4. モデルはまた、リポジトリや強力な型への結果の投影を考慮する必要があります（EFには優れたメソッドがあります... EF.Database.Select（querystring、parms）直接ADOアクセスでクエリを挿入して強力な型を取得します。これはEFに対処します遅い議論ですEFは遅いではありません！
5. ViewModelはデータを取得し、ビジネスルールと検証を行います
6. 上のコントローラポストバックは ViewModelにPostメソッドをCALし、結果を待ちます。
7. コントローラーは新しく更新されたビューモデルをビューに挿入します。ビューは強い型バインディングのみを使用します。
8. ビューは単にデータをレンダリングし、イベントをコントローラーにポストします。（以下の例を参照）
9. MVCはインバウンド要求をインターセプトし、強力なデータタイプを持つ適切なコントローラーにルーティングします

このモデルでは、MSFTのMVCマシンが要求または応答オブジェクトを隠すため、要求または応答オブジェクトとのHTTPレベルの連絡はありません。

上記の項目6の説明（リクエストによる）...

次のようなViewModelを想定します。

public class myViewModel{
     public string SelectedValue {get;set;}
public void Post(){
    //due to MVC model binding the SelectedValue string above will be set by MVC model binding on post back.
    //this allows you to do something with it.
    DoSomeThingWith(SelectedValue);
    SelectedValue = "Thanks for update!";
 }
}

投稿のコントローラーメソッドは次のようになります（以下を参照）。mvmのインスタンスはMVCバインディングメカニズムによって自動的にインスタンス化されることに注意してください。結果として、クエリ文字列レイヤーにドロップダウンする必要はありません！これは、クエリ文字列に基づいてViewModelをインスタンス化するMVCです。

[HTTPPOST]   
public ActionResult MyPostBackMethod (myViewModel mvm){
         if (ModelState.IsValid)
        {
               // Immediately call the only method needed in VM...
               mvm.Post()
        }
      return View(mvm);
}

上記のこのアクションメソッドが意図したとおりに機能するためには、投稿で返されないものを初期化するnull CTORが定義されている必要があります。ポストバックは、変更されたものの名前/値のペアもポストバックする必要があります。名前/値のペアが欠落している場合、MVCバインディングエンジンは適切な処理を行いますが、これは単に何もしません。これが発生した場合、「ポストバックでデータを失っています」と自分に気付くかもしれません...

このパターンの利点は、ViewModelがモデル/ビジネスロジックに接続するすべての「煩雑な」作業を実行することです。コントローラーは一種のルーターにすぎません。稼働中のSOCです。

MVVMはビューモデルをミックスに追加します。これにより、通常のモデルにUI固有の要素をすべて配置することなく、WPFの多くのバインディングアプローチを使用できるようになるため、これは重要です。

私は間違っているかもしれませんが、MVVMが本当にコントローラーを強制的にミックスに含めるかどうかはわかりません。このコンセプトはhttp://martinfowler.com/eaaDev/PresentationModel.htmlに沿っていると思います。パターンに組み込まれているのではなく、MVCと組み合わせることを選択する人がいると思います。

私が知ることができることから、MVVMはMVCのMVにマップされます。つまり、従来のMVCパターンでは、VはMと直接通信しません。MVCの2番目のバージョンでは、MとVの間に直接リンクがあります。MVVMは、MおよびV通信に関連するすべてのタスクを実行し、それらを結合してCから切り離すように見えます。実際には、MVVMで完全に考慮されていない、より大きなスコープのアプリケーションワークフロー（または使用シナリオの実装）がまだあります。これがコントローラーの役割です。これらの下位レベルの要素をコントローラーから削除することにより、これらの要素がよりクリーンになり、アプリケーションの使用シナリオとビジネスロジックを変更しやすくなり、コントローラーの再利用性も向上します。

これは、MVVM の起源に言及せずに非常に投票された回答であることを驚かせます。MVVMは、Microsoftコミュニティで使用される一般的な用語であり、Martin Fowlerのプレゼンテーションモデルに由来します。したがって、パターンの動機と他の人との違いを理解するために、パターンに関する最初の記事を最初に読んでください。

まあ、一般的にMVCはWeb開発で使用され、MVVMはWPF / Silverlight開発で最も人気があります。ただし、WebアーキテクトにはMVCとMVVMが混在している場合があります。

たとえば、knockout.jsを使用すると、クライアント側にMVVMが存在します。また、MVCのサーバー側も変更できます。複雑なアプリでは、誰も純粋なモデルを使用しません。ViewModelをMVCの「モデル」として使用することには意味があり、実際のモデルは基本的にこのVMの一部になります。これにより、追加の抽象化レイヤーが得られます。

MVVMC、またはおそらくMVC +は、エンタープライズおよび迅速なアプリケーション開発にとって実行可能なアプローチのようです。UIをビジネスロジックと対話ロジックから分離するのは良いことですが、「純粋な」MVVMパターンとほとんどの利用可能な例は、単一のビューで最適に機能します。

あなたのデザインはわかりませんが、ほとんどのアプリケーションにはページといくつかの（再利用可能な）ビューが含まれているため、ViewModelはある程度対話する必要があります。ページをコントローラーとして使用すると、MVVMの目的が完全に無効になるため、基礎となるロジックに「VM-C」アプローチを使用しないと、アプリケーションが成熟するにつれて、構成要素が困難になる可能性があります。VB-6でも、ほとんどの場合、ビジネスロジックのボタンイベントへのコーディングを停止し、コントローラーへのコマンドの「リレー」を開始しました。私は最近、そのトピックに関する多くの新しいフレームワークを調べました。私のお気に入りは明らかにマゼラン（コードプレックス）アプローチです。幸せなコーディング！

http://en.wikipedia.org/wiki/Model_View_ViewModel#References

ViewModelにはコントローラーとはまったく異なる機能があるため、MVVMではコントローラーはViewModelに置き換えられません。コントローラーが必要です。コントローラーがなければ、モデル、ViewModel、およびViewはあまり機能しません。

MVVMCは私の控えめな意見では正しい名前です。

ご覧のとおり、ViewModelはMVCパターンへの追加にすぎません。変換ロジック（オブジェクトを文字列に変換するなど）をコントローラーからViewModelに移動します。

これのためにMediumの記事を作りました。

MVVM

1. 表示➡ViewModel➡モデル

   • ビューにはViewModelへの参照がありますが、その逆はありません。
   • ViewModelにはモデルへの参照がありますが、その逆はありません。
   • ビューはモデルを参照せず、その逆も同様です。

2. コントローラーを使用している場合、コントローラーはViewsおよびViewModelsへの参照を持つことができますが、SwiftUIで示されているように、コントローラーは必ずしも必要ではありません。

3. データバインディング：ViewModelプロパティのリスナーを作成します。

class CustomView: UIView {
  var viewModel = MyViewModel {
    didSet {
      self.color = viewModel.color
    }
  }

  convenience init(viewModel: MyViewModel) {
    self.viewModel = viewModel
  }
}


struct MyViewModel {
   var viewColor: UIColor {
      didSet {
         colorChanged?() // This is where the binding magic happens.
      }
   }

   var colorChanged: ((UIColor) -> Void)?
}


class MyViewController: UIViewController {

   let myViewModel = MyViewModel(viewColor: .green)
   let customView: CustomView!

   override func viewDidLoad() {
      super.viewDidLoad()

      // This is where the binder is assigned.
      myViewModel.colorChanged = { [weak self] color in 
        print("wow the color changed")
      }
      customView = CustomView(viewModel: myViewModel)
      self.view = customView
   }
}

セットアップの違い

1. ビジネスロジックは、MVCのコントローラーとMVVMのViewModelsに保持されます。
2. イベントは、ビューからMVCのコントローラーに直接渡されますが、MVVMの場合、イベントはビューからViewModel、コントローラー（存在する場合）に渡されます。

一般的な機能

1. MVVMとMVCはどちらも、ビューがモデルに直接メッセージを送信することを許可していません。
2. どちらにもモデルがあります。
3. どちらにもビューがあります。

MVVMの利点

1. ViewModelはビジネスロジックを保持するため、単体テストを簡単にする小さな具象オブジェクトです。一方、MVCでは、ビジネスロジックはViewControllerにあります。すべてのメソッドとリスナーを同時にテストせずに、ビューコントローラーの単体テストが包括的に安全であることをどのように信頼できますか？単体テストの結果を完全に信頼することはできません。
2. MVVMでは、ビジネスロジックがコントローラーからアトミックなViewModelユニットに吸い上げられるため、ViewControllerのサイズが小さくなり、これによりViewControllerコードが読みやすくなります。

MVCの利点

1. コントローラ内にビジネスロジックを提供すると、分岐の必要性が減少するため、ステートメントがキャッシュで実行される可能性が高くなり、ビジネスロジックをViewModelにカプセル化するよりもパフォーマンスが向上します。
2. ビジネスロジックを1か所に提供すると、テストが不要な単純なアプリケーションの開発プロセスを加速できます。テストが不要な時期はわかりません。
3. 新規の開発者にとって、ViewControllerにビジネスロジックを提供することは簡単に考えることができます。

実用的な観点から見ると、MVC（Model-View-Controller）はパターンです。ただし、MVCをASP.net MVCとして使用する場合、Entity Framework（EF）および「パワーツール」と組み合わせると、データベース、テーブル、および列をWebページに完全に自動化する非常に強力な、部分的に自動化されたアプローチとなります。 CRUD操作またはR（取得または読み取り）操作のみ。少なくとも私がMVVMを使用していたとき、ビューモデルはビジネスオブジェクトに依存するモデルと相互作用し、モデルは「手作り」であり、多くの努力の結果、EFが提供するものと同じくらい優れたモデルを得ることができました。 -of-the-box "。実用的なプログラミングの観点から見ると、MVCはすぐに使用できるユーティリティを1つ多く提供するため、良い選択のように見えますが、追加機能がまだ追加されている可能性があります。

与えられた多くの応答を補完するものとして、私は現代のクライアント側WebまたはリッチWebアプリケーションの観点からいくつかの追加の視点を追加したいと思いました。

実際、最近では、シンプルなWebサイトや大規模なWebアプリケーションが、Bootstrapなどの多くの一般的なライブラリで構築されています。Steve Sandersonによって構築されたKnockoutは、パターンの最も重要な動作の1つであるビューモデルによるデータバインディングを模倣するMVVMパターンをサポートします。小さなJavaScript data-bindを使用して、Bootstrapの多くの機能を使用するのと同じように、単純なHTML属性を持つページ要素に追加できるデータとロジックを実装できます。これら2つのライブラリーだけで、インタラクティブなコンテンツが提供されます。このアプローチをルーティングと組み合わせると、シングルページアプリケーションを構築するためのシンプルでありながら強力なアプローチが得られます。。

同様に、Angularなどの最新のクライアント側フレームワークは、慣例によりMVCパターンに従いますが、サービスも追加します。興味深いことに、Model-View-Whatever（MVW）として宣伝されています。（Stack Overflowのこの投稿を参照してください。）

さらに、Angular 2などのプログレッシブ Webフレームワークの台頭に伴い、用語が変化し、おそらくコンポーネントがビューまたはテンプレートで構成され、サービスと対話する新しいアーキテクチャパターンが見られます。これらはすべて、モジュール; そして、一連のモジュールがアプリケーションを構成します。

MVCとMVVMは同じだと思っていました。今フラックスの存在のために私は違いを知ることができます：

MVCでは、アプリのビューごとにモデルとコントローラーがあるので、ビュー、ビューモデル、ビューコントローラーと呼びます。パターンは、1つのビューが別のビューとどのように通信できるかを示しません。したがって、異なるフレームワークでは、そのための異なる実装があります。たとえば、コントローラが相互に通信する実装がありますが、他の実装では、それらの間を仲介する別のコンポーネントがあります。ビューモデルが相互に通信する実装もあり、ビューモデルはビューコントローラーだけがアクセスする必要があるため、これはMVCパターンの中断です。

MVVMには、各コンポーネントのビューモデルもあります。このパターンは、ビューがビューモデルにどのように影響するかを指定するものではないため、通常、ほとんどのフレームワークは、ビューモデルにコントローラーの機能を組み込んでいます。ただし、MVVMは、ビューモデルのデータは、特定のビューに対応していない、またはカスタムではないモデル全体であるモデルから取得する必要があることを通知します。

違いを示すために、フラックスパターンを見てみましょう。Fluxパターンは、アプリのさまざまなビューがどのように通信する必要があるかを示します。各ビューはストアをリッスンし、ディスパッチャーを使用してアクションを起動します。ディスパッチャは今度は、行われたアクションについてすべてのストアに通知し、ストアは自身を更新します。Fluxのストアは、MVVMの（一般的な）モデルに対応しています。特定のビューに合わせたものではありません。したがって、通常、ReactとFluxを使用する場合、各Reactコンポーネントは実際にMVVMパターンを実装します。アクションが発生すると、ビューモデルがディスパッチャーを呼び出し、最後にモデルであるストアの変更に応じてディスパッチャが更新されます。MVCではコントローラーのみがビューモデルを更新できるため、各コンポーネントがMVCを実装しているとは言えません。

Web開発では、mvcはサーバー側で、mvvmはクライアント側（ブラウザ）です。

ほとんどの場合、JavaScriptはブラウザのmvvmに使用されます。mvcには多くのサーバー側テクノロジーがあります。

非常に簡単に言えば、MVCでは、Controlerは（コントロール）ビューを認識していますが、MVVMでは、ViewModelは誰がビューを使用するかを認識していません。ViewModelは、その監視可能なプロパティとアクションを、それを使用することに関心のある人に公開します。ViewModel内のUIへの参照がないため、この事実によりテストが容易になります。

モデルビューコントローラー（通常はMVCと呼ばれます）は、関連するプログラムロジックを3つの相互接続された要素に分割するユーザーインターフェイスの開発に一般的に使用されるソフトウェア設計パターンです。これは、情報の内部表現を、ユーザーへの情報の提示方法と受け入れ方法から分離するために行われます。MVCアーキテクチャパターンに従うと、これらの主要なコンポーネントが分離され、コードの再利用と並行開発が可能になります。

従来、デスクトップのグラフィカルユーザーインターフェイス（GUI）に使用されていたこのパターンは、Webアプリケーションの設計で広く使用されています。JavaScript、Python、Ruby、PHP、Java、C＃などの人気のあるプログラミング言語には、そのままWebアプリケーション開発で使用されるMVCフレームワークがあります。

型番

パターンの中心コンポーネント。これは、ユーザーインターフェースに依存しない、アプリケーションの動的データ構造です。アプリケーションのデータ、ロジック、ルールを直接管理します。

見る

チャート、図、表などの情報の表現。管理用の棒グラフや会計士用の表形式ビューなど、同じ情報の複数のビューが可能です。

コントローラ

入力を受け入れ、それをモデルまたはビューのコマンドに変換します。

アプリケーションをこれらのコンポーネントに分割することに加えて、モデル、ビュー、コントローラーの設計は、コンポーネント間の相互作用を定義します。

モデルは、アプリケーションのデータを管理する責任があります。コントローラからユーザー入力を受け取ります。

ビューとは、特定の形式でモデルを表示することを意味します。

コントローラーはユーザー入力に応答し、データモデルオブジェクトの操作を実行します。コントローラーは入力を受け取り、オプションでそれを検証してから、入力をモデルに渡します。

Model–View–ViewModel（MVVM）は、ソフトウェアアーキテクチャパターンです。

MVVMは、マークアップ言語またはGUIコードを介して、グラフィカルユーザーインターフェイスの開発を、ビジネスロジックまたはバックエンドロジック（データモデル）の開発から分離することを容易にします。MVVMのビューモデルは値コンバーターです。つまり、ビューモデルは、オブジェクトを簡単に管理および表示できるように、モデルからデータオブジェクトを公開（変換）します。この点で、ビューモデルはビューよりもモデルであり、ビューの表示ロジックのすべてではなくてもほとんどを処理します。ビューモデルは、メディエーターパターンを実装し、ビューでサポートされている一連のユースケースを取り巻くバックエンドロジックへのアクセスを整理します。

MVVMは、Martin Fowlerのプレゼンテーションモデルデザインパターンのバリエーションです。MVVMはビューの状態と動作を同じ方法で抽象化しますが、プレゼンテーションモデルは特定のユーザーインターフェイスプラットフォームに依存しない方法でビューを抽象化（ビューモデルを作成）します。

MVVMは、Microsoftのアーキテクトであるケンクーパーとテッドピーターズによって、ユーザーインターフェイスのイベント駆動型プログラミングを簡素化するために特別に開発されました。このパターンは、Windows Presentation Foundation（WPF）（Microsoftの.NETグラフィックスシステム）およびSilverlight（WPFのインターネットアプリケーション派生物）に組み込まれました。MicrosoftのWPFおよびSilverlightアーキテクトの1人であるJohn Gossmanは、2005年に彼のブログでMVVMを発表しました。

Model-View–ViewModelは、特に.NETプラットフォームを含まない実装では、モデル–ビューバインダーとも呼ばれます。ZK（Javaで記述されたWebアプリケーションフレームワーク）およびKnockoutJS（JavaScriptライブラリ）は、モデル、ビュー、バインダーを使用します。