1395

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

4

25 に答える 25

725

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

2 つのパターンは、ASP.Net と Silverlight/WPF の両方の開発で、さまざまな方法で発生します。

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

Silverlight と WPF の場合、MVVM パターンはより包括的であり、MVC (またはソフトウェアを個別の役割に編成する他のパターン) の代わりとして機能するように見える可能性があります。このパターンから頻繁に出てくる 1 つの仮定はViewModel、コントローラーを単純に置き換えたというものでした (頭字語を単に置き換えることができ、すべてが許されるかのように) MVC...VMC

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 の幅広い使用について説明し、コントローラーを ViewModel に置き換えることを思いとどまらせることを目的としています。

于 2010-08-22T09:19:15.567 に答える
181

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

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

Russel Eastは、 MVVM が MVC と異なる理由について詳しく説明しているブログを作成しています。

于 2009-03-20T20:18:53.747 に答える
98

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

モデル/ビュー/ビューモデル アーキテクチャの主な目的は、データ (「モデル」) の上に、データの概念をより密接にマッピングする非ビジュアル コンポーネント (「ビューモデル」) の別のレイヤーがあることです。データのビュー (「ビュー」) の概念に。View がバインドされるのは ViewModel であり、Model に直接ではありません。

于 2009-03-20T20:17:36.383 に答える
57

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

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

Model-View-ViewModel 設計パターンでは、アプリは 3 つの一般的なコンポーネントで構成されます。ここに画像の説明を入力

  • Model : これは、アプリが使用するデータ モデルを表します。たとえば、写真共有アプリでは、このレイヤーは、デバイスで使用できる一連の写真と、写真ライブラリの読み取りと書き込みに使用される API を表す場合があります。

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

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

于 2013-06-12T20:48:46.460 に答える
51

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

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

于 2010-05-21T11:38:25.723 に答える
36

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

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

MVVM はリアクティブ環境であり、通常、何らかのイベントに基づいてアクティブ化されるコード (トリガーなど) を記述します。MVVM が盛んな XAML では、これは組み込みのデータバインディング フレームワークを使用してすべて簡単に実行できますが、前述のように、これは任意のプログラミング言語を使用する任意のビューの任意のシステムで機能します。これは 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 はその状態をリッスンして変換します。それだけです!!! その後、View は ViewModel の状態変更をリッスンし、ViewModel からの変換に基づいて更新も行います。一部の人々はそれを純粋なMVVMと呼んでいますが、実際には1つしかありません。あなたがそれをどのように主張するかは気にしません。ビューにロジックがまったく含まれていないのは常に純粋なMVVMです。

ここにちょっとした例があります: ボタンを押してメニューをスライドさせたいとしましょう。MVC では、インターフェイスに MenuPressed アクションがあります。コントローラーは、ユーザーがメニュー ボタンをクリックしたことを認識し、SlideMenuIn などの別のインターフェイス メソッドに基づいて、メニューにスライドするようにビューに指示します。何のための往復？コントローラーが、代わりに何か他のことをできない、またはしたいと判断した場合、それが理由です。コントローラーは、コントローラーがそうしない限り、ビューを担当する必要があります。ビューは何もしません。でも; MVVM では、アニメーションのスライド メニューは組み込みで汎用的である必要があり、スライドするように指示される代わりに、何らかの値に基づいてスライドします。したがって、ViewModel をリッスンし、ViewModel が IsMenuActive = true (またはただし) と言うと、そのアニメーションが発生します。今、そうは言っても、私は別の点を本当に明確にしたいと思います。注意してください。IsMenuActive は、おそらく不適切な MVVM または ViewModel 設計です。ViewModel を設計するときは、View に何らかの機能があると想定してはならず、変換されたモデルの状態を渡すだけにしてください。そうすれば、ビューを変更してメニューを削除し、データ/オプションを別の方法で表示することにした場合、ViewModel は気にしません。では、メニューをどのように管理しますか? データが理にかなっている場合、それがその方法です。したがって、これを行う 1 つの方法は、Menu にオプションのリスト (おそらく内部の ViewModel の配列) を与えることです。そのリストにデータがある場合、メニューはトリガーを介して開くことを認識し、そうでない場合は、トリガーを介して非表示にすることを認識します。メニューのデータがあるか、ViewModel にないだけです。ViewModel でそのデータの表示/非表示を決定しないでください。モデルの状態を単純に変換します。このように、ビューは完全にリアクティブで汎用的であり、さまざまな状況で使用できます。

それぞれのアーキテクチャに少なくとも少し慣れていない場合、これらすべてはおそらくまったく意味がありません。ネット上で多くの悪い情報が見つかるため、それを学ぶことは非常に混乱する可能性があります.

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

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

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

これが私の最後のヒントです...よく設計されているが非常に単純な MVC アプリケーションを見て、MVVM アプリケーションに対して同じことを行います。一方は柔軟性がゼロに制限されており、もう一方は制御がなく、柔軟性が無制限です。

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

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

結局のところ、私たちは皆プログラマーであり、コーディングするときはその無秩序が私たちの中に住んでいます...したがって、ルールは破られ、理論は変化し、これらすべてが独り占めになるでしょう...しかし、大規模な作業を行う場合プロジェクトや大規模なチームでは、設計パターンに同意してそれを適用することが非常に役立ちます。いつの日か、最初に取った小さな余分なステップが、後で飛躍的な節約になるでしょう。

于 2017-01-25T05:15:21.007 に答える
31

単純な違い: (Yaakov の Coursera AngularJS コースに触発された)

ここに画像の説明を入力

MVC (モデル ビュー コントローラー)

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

MVVM (モデル ビュー ビュー モデル)

ビューモデル:

  1. ビューの状態の表現です。
  2. ビューに表示されるデータを保持します。
  3. ビュー イベント、別名プレゼンテーション ロジックに応答します。
  4. ビジネス ロジック処理のための他の機能を呼び出します。
  5. ビューに何かを表示するように直接要求することはありません。
于 2016-12-14T00:20:05.407 に答える
19

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

于 2009-03-27T21:22:48.900 に答える
16

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

MVC を使用したことがある場合は、ビューの状態を反映するモデル オブジェクトを作成すると、たとえば、編集ダイアログの表示と非表示などを行うのに役立つことがあると思います。その場合、viewmodel を使用しています。

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

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

于 2010-03-23T10:16:15.053 に答える
13

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

于 2014-08-26T06:23:32.120 に答える
10

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

  1. コントローラーは、ViewModel を新しく作成し、View に挿入する役割を果たします。(get リクエストの場合)
  2. ViewModel は、DataContext のコンテナーであり、最後に選択された項目などのビュー ステートです。
  3. モデルには DB エンティティが含まれており、クエリとフィルタリングを行う DB スキーマに非常に近いです。（これにはEFとLINQが好きです）
  4. モデルは、リポジトリや結果の強力な型への射影も考慮する必要があります (EF には優れた方法があります... EF.Database.Select(querystring, parms) は、ADO に直接アクセスしてクエリを挿入し、強力な型を取得します。これは EF に対応します。は遅い引数です. EF は SLOW ではありません!
  5. ViewModel はデータを取得し、ビジネス ルールと検証を行います
  6. ポストバックのコントローラーは、ViewModel の Post メソッドを呼び出し、結果を待ちます。
  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です。

于 2014-10-15T13:58:29.890 に答える
9

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

于 2010-08-22T07:42:43.773 に答える
9

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

私は間違っているかもしれませんが、MVVM が実際にコントローラーをミックスに強制するかどうかはわかりません。この概念は、http://martinfowler.com/eaaDev/PresentationModel.htmlとより一致していると思います。パターンに組み込まれているわけではなく、MVC と組み合わせることを選択していると思います。

于 2009-03-20T20:20:58.297 に答える
4

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

あなたのデザインについてはわかりませんが、私のアプリケーションのほとんどにはページといくつかの (再利用可能な) ビューが含まれているため、ViewModel はある程度対話する必要があります。ページをコントローラーとして使用すると、MVVM の目的が完全に無効になるため、基になるロジックに "VM-C" アプローチを使用しないと、アプリケーションが成熟するにつれて複雑な構造になる可能性があります。VB-6 でさえ、私たちのほとんどはおそらくビジネス ロジックを Button イベントにコーディングするのをやめて、コマンドをコントローラーに「中継」し始めたのではないでしょうか? 私は最近、そのトピックに関する多くの新しいフレームワークを見てきました。私のお気に入りは明らかに (codeplex での) Magellan アプローチです。ハッピーコーディング！

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

于 2010-10-09T06:17:24.507 に答える
2

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

于 2014-12-17T17:53:05.423 に答える