web-dev-qa-db-ja.com

MVVMパターンにおけるView-firstとViewModel-firstの長所と短所は何ですか

実世界のアプリケーションでのMVVMの使用に関するプレゼンテーションを行っています。 宗教戦争 MVVMをアプリケーションのパターンとして使用する場合の設計上の決定。 MVVMアプリケーションでは、新しいView/ViewModelペアをインスタンス化する主な方法が2つあります（私が知っています）。

  1. View-Firstここで、ビューを作成し、独自のViewModelを作成して、それをDataContextに設定します。
  2. ViewModel-Firstここでは、新しいビューモデルを作成し、ViewModelプロパティの変更に応じて新しいビューを作成します。通常、ItemsControlsやDataTemplatesを使用します。

あなたの経験では、各方法の長所と短所は何ですか？それらによって何が可能になり、それぞれにどのような問題が発生しますか？

結果のまとめ

  • 最初に表示-長所
    • ビューで使用されているViewModelを簡単に追跡
  • 最初に表示-短所
    • 単一のビューを複数のビューモデルで簡単に使用することはできません
    • ビューとViewModel間の通信を処理するには、追加のイベントが必要です
  • ViewModel First-長所
    • ロジックのより完全なテストにより、新しいビューとビューモデルを開くことができます
    • アプリケーションが大きくなるにつれて、より乾燥する傾向がある
    • ViewとViewModelはより独立しており、個別に簡単に作業できます
  • ViewModel First-短所
    • DataTemplateSelectorと入力されたDataTemplatesがないと、Silverlightでのセットアップがより困難になります。
mvvm
48
Bryan Anderson

WPFのデータテンプレート機能を考えると、ViewModel-FirstはWPFがintendedを使用する方法であると感じています。

そのステートメントを明確にします。データテンプレートを使用すると、ViewModelからビューをインスタンス化できなくなります。正しく行われると、ビューとViewModelは、互いに参照しない別々のプロジェクトに保持される可能性があります。さらに、ViewModelプロジェクトはPresentationFrameworkアセンブリを参照してはならず、考えられるユーザーがViewModelを利用できるようにする必要があります。

17
Andre Luus

DRYルールが最善であると感じたからといって、最初にビューモデルを優先する傾向があります。大規模なアプリケーションの作成を開始すると、テストが容易になるため、最初のビットよりも重要です。アプリケーションを設定するときに対処する必要がある頭痛の種。

5
Kavet Kerek

警告-私はSilverlightではなくWPFを使用しています。

VM Vをインスタンス化することで（これは私が行う方法です）、ビューは独立しており、VMから独立して使用できます（たとえば、デザイナーで）

個人的には、MVVMC（モデル、ビュー、ビューモデル、コントローラー）に向かっています。そこでは、ViewModelとビューをインスタンス化して「結合」する制御クラスがあります。 Cはまた、データの取得（およびキャッシュなど）およびVMとVs間の通信を処理します（たとえば、Vがインスタンス化されている場合、コマンドをVMいくつかのアクションを実行するには、VMはおそらくCに代わってアクションを実行するように要求します;その後、Cは他のVMが処理できる適切なイベントを発生させることができます

（コントローラを使用するかどうかにかかわらず）VMが別のVMと通信する必要がある場合、VがVM- VMをVで公開する必要がないためです（または、少なくとも2番目のVMが1番目と通信できるように、いくつかのインターフェイスを使用可能にする必要があります）。

4
Maxxx

私はビューモデルの最初のアプローチを使用することを好みます。多くの理由から：

  • VMは、動作またはトリガーの形式のグルーコード以外のほとんどのロジックを含むアプリケーションです。
  • ビューを作成する場合は、そのライフとクリーンアップコードの責任があります。テストが難しいスレッドやその他の問題に対処する必要があります。一方、vmsを作成し、ビューの作成ロジックはデータテンプレート経由でWPFのままにします。スレッドの問題を心配する必要はありません。そして、懸念の分離が改善されます。
  • VMの最初のアプローチでは、コードの背後にゼロを設定します。
  • ビューとvmsのプロジェクトレベルの分離を使用すると、ビューモデルでディスパッチャーなどのビュー固有のものを使用する開発者を制限して、よりクリーンでテスト可能なコードベースを残すことができます。つまり、プロジェクトsprojecをvmに表示します。また、vmプロジェクトはプレゼンテーションライブラリを参照しないでください。
  • ビューとvmの間に明確な境界がある場合。どちらも進化する可能性があり、壊れにくくなります。
1
Rajnish Noonia

私たちは最初にViewModelを使用しましたが、アウトソーシングで、ブレンドの使用が最も重要なことになったとき、上司はView-firstがViewmodel-firstより優れていると言いました-私は彼に同意しませんでした（ただし、1対多は最高の比率ではありません）投票数;-)）、なぜならコードビハインドでビューのイベントといくつかの奇妙な関係があるからです。今、私は取り返しのつかないところにあり、変更のためにいくつかのカスタムコントロールで立ち往生しています。

1
OldTimer

私はビューファースト（ソート）アプローチを使用しています。テストデータを含むダミービューモデルを使用して、クライアントと共同でビューを定義します。満足したら、「ダミー」からインターフェースを抽出し、実際のViewModelを実装します。次の理由から、このアプローチが最も魅力的であることがわかりました。

  • プロトタイピングは時間的に安価であり、4回目または5回目の試行でそれを正しく（多分）得ることが多いので、高速です。
  • 準拠するインターフェースがある場合、ViewModelは簡単に（簡単に）実装できる傾向があります。

私はWPFで働いていますが、SLでもそれほど変わらないと思います。また、私のアプローチの選択に起因する可能性のあるビューのテストに時間を費やすことはありません。

0
Goblin