MVVMと他のMV *パターンの違い

翻訳者から ：

MVCとその派生パターンに関する多くの資料を既に公開していますが、誰もが独自の方法でそれらを理解しています。 これに基づいて、意見の相違や意見の相違が生じます。 経験豊富な開発者でさえ、MVP、MVVM、およびプレゼンテーションモデルの違いと、各パターンでコンポーネントが何をすべきかについて議論します。 状況は、多くの人がMVCのクラシックバージョンでのコントローラーの真の役割を知らないという事実によって悪化します。 良いレビュー記事の翻訳をあなたの注意に持っていきます 。

Model-View-ViewModel（MVVM）パターンの詳細を詳しく説明する前に、MVVMとモデルとプレゼンテーションを分離する他のデザインパターン（MV *パターン）の類似点と相違点を説明しておくと役立つと思います。

MV *パターンにはかなりの数があります。Model-View-Controller、Model-View-Presenter、Presentation Model、Passive View、Supervising Controller、Model-View-ViewModelなどです。

もちろん、図を見ると、矢印がコンポーネント間の関係を示していることがわかります。 しかし、これが唯一の違いですか？ コントローラーはPresenterまたはPresentationModelと同じですか？ Model-View-PresenterとModel-View-ViewModelをどのように比較しますか？ この記事では、最も一般的なMV *パターンの類似点と相違点について説明します。

MV *パターンを使用せずにUIを構築する

上記のパターンを使用せずに、どのようにユーザーインターフェイス（UI）を構築しますか？ 彼らはフォームを取り、それにウィジェットを追加し、コードでロジックを記述します。 Viewのロジックを記述するこのようなコードは、画面上の要素と直接やり取りするため、ユーザーインターフェイスと密接に接続されています。 これは良いが、簡単なアプローチです。 非常にシンプルなインターフェイスにのみ適用できます。 ロジックがより複雑になると、そのようなUIのサポートは悪夢に変わる可能性があります！

問題の根本は、この方法でUIを構築すると、「 クラスには変更の理由が1つだけあるはずです」という単一の責任原則に違反することです。 UIコンポーネントに表示、ロジック、およびデータのコードが含まれている場合、変更する理由がいくつかあります。 たとえば、データの表示に使用されるユーザー要素のタイプを変更する場合、変更はロジックに影響を与えません。 ただし、ロジックはコントロールと非常に密接に関連しているため、変更する必要もあります。 これはいわゆる「コード臭 」であり、唯一の責任の原則に違反していることを示しています。

したがって、フォームにコントロールを表示するためのコード、インターフェースのロジック（ボタンが押されたときの動作）、および画面に表示するためのデータが含まれている場合、次の問題が発生します。

• 複雑なサポート
  
  UI、ロジック、またはデータの変更は、残りの部分の変更を伴う可能性があります。 したがって、編集を行うことははるかに困難であり、保守が難しくなります。

  
  
  
  
  
  
  

• 試験性の悪化
  
  各コンポーネントを個別にテストできるように、アプリケーションのロジックとデータを記述できます。 ただし、ユーザーインターフェイスに関連付けられたコードは、UIでロジックを実行するためにユーザーの関与を必要とすることが多いため、単体テストには適していません。 さらに、多くの場合、視覚化には、すべてが「正しく見える」という人による評価が必要です。 ユーザーインターフェイステストを自動化するソリューションがあることに注意してください。 ただし、ユーザーインタラクションのみをシミュレートします。 原則として、それらは単体テストよりも構成および保守が難しく、アプリケーション全体を起動する必要があるため、統合テストで最もよく使用されます 。

  
  
  
  
  
  
  
• 再利用性の低下
  
  UIコードにロジックコードとデータコードが混在している場合、再利用がはるかに困難になります。

MV *パターンの目的

各パターンにはかなりの違いがありますが、それらの目標は似ています。UIコード（View）をロジックコード（Presenter、Controller、ViewModelなど）およびデータ処理コード（Model）から分離することです。 これにより、それぞれが独立して開発できます。 たとえば、ロジックとデータに影響を与えることなく、アプリケーションの外観とスタイルを変更できます。

さらに、ロジックとデータはディスプレイとは別なので、別々にテストできます。 単純なアプリケーションの場合、これはそれほど重要ではありません。 たとえば、アプリケーションが単純なデータエディターである場合。 ただし、より複雑なインターフェイスロジックがある場合、正しく動作することを自動的に確認する機能は非常に価値があります。

モデルビューコントローラー

ビューをロジックとモデルから分離する最初のパターンの1つは、 Model-View-Controller （MVC）です。 この概念はTrygve Reenskaugomによって説明されました 。

1979年に！ （私は生まれもしませんでした）。

このパターンは、Smalltalkでアプリケーションを作成するために開発されました。 しかし、当時は、プログラミングは今日のようではありませんでした。 窓はありませんでした。 グラフィカルユーザーインターフェイスはありませんでした。 ウィジェットライブラリはありませんでした。 ユーザーインターフェイスが必要な場合は、自分で作成する必要があります。 または、キーボードなどの入力デバイスとやり取りする場合。

しかし、Trygveが行ったことは非常に革新的でした。 全員が表示コード、ロジック、およびデータを混在させた場合、彼はパターンを適用して、これらの責任を別々のクラス間で共有しました。

MVCパターンの問題は、おそらく世界で最も誤解されているパターンの1つであることです。 そして、これは名前のおかげだと思います。 Trygveは最初にModel-View-Editorパターンを呼び出しましたが、後にModel-View-Controllerに落ち着きました。 モデル（データ）とビュー（画面に表示されるもの）が明確です。 しかし、コントローラーとは何ですか？ アプリケーションコントローラーはMVCパターンと同じですか？ （ いいえ、しかし、混乱の原因はわかります ）。

これらのモデル、ビュー、コントローラーは何ですか：

• モデル
  
  モデルは、アプリケーションのデータ、それらを取得して保存するロジックです。 多くの場合、これはデータベースまたはWebサービスの結果に基づくドメインモデルです。 場合によっては、 ドメインモデルは画面に表示されるものにうまく投影されます。 ただし、使用する前に、適応、変更、拡張する必要がある場合があります。

  
  
  
  
  
  
  

• 表示する
  
  ビューは、画面にUIを表示する役割を果たしました。 ウィジェットライブラリがなければ、これはブロック、ボタン、入力フィールドなどの自己レンダリングを意味しました。Viewはモデルを監視し、そこからデータを表示することもできます。

  
  
  
  
  
  
  
• コントローラー
  
  コントローラーはユーザーアクションを処理し、モデルまたはビューを更新します。 ユーザーがアプリケーションと対話する（キーボードのボタンを押す、マウスカーソルを移動する）場合、コントローラーはこれらのアクションに関する通知を受け取り、アクションの処理方法を決定します。

翻訳者からのメモ：

Controllerは、Viewではなく入力イベントを直接受信することに注意してください。 コントローラーはキーボードまたはマウスからのユーザー入力を解釈し、モデルまたはビューにコマンドを送信して適切な変更を加えます。

コントローラーが「クリーンな」MVC実装でどのように見えるかを示す簡単な例を作成しました。 通常のasp.net（asp.net MVCではない）に実装しましたが、ユーザーコントロールは使用しません。 したがって、これはより伝統的なASPスタイルです。 （ はい、これはあまり良い例ではありませんが、コントローラーの本当の役割を理解するための出発点になることを願っています ）。

public class Controller { private readonly IView _view; public Controller(IView view) { _view = view; HttpRequest request = HttpContext.Current.Request; if (request.Form["ShowPerson"] == "1") { if (string.IsNullOrEmpty(request.Form["Id"])) { ShowError("The ID was missing"); return; } ShowPerson(Convert.ToInt32(request.Form["Id"])); } } private void ShowError(string s) { _view.ShowError(s); } private void ShowPerson(int Id) { var model = new Repository().GetModel(Id); _view.ShowPerson(model); } }
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

長年後、プログラミングのパラダイムは少し変わりました-ユーザーコントロール（ ウィジェット ）があります。 ウィジェットは、自身をレンダリングし、ユーザー入力を解釈します。 ボタンは、クリックしたときに何をすべきかを知っています。 入力フィールドは、テキストを入力した場合の処理​​を認識しています。 これにより、コントローラーの必要性が減り、MVCパターンの関連性が低くなりました。 ただし、アプリケーションロジックをプレゼンテーションとデータから分離する必要があるため、Model-View-Presenter（MVP）と呼ばれる別のパターンが人気を集めています。

MVCパターンのほとんどの例は、テキストボックス実装やボタン実装などの非常に小さなコンポーネントに焦点を当てています。 最新のユーザーインターフェイステクノロジ（Visual Basic 3はSmalltalk 1979と比較して最新です）を使用する場合、通常、このパターンは必要ありません。 ただし、非常に低レベルのAPI（Direct Xなど）を使用してウィジェットを設計している場合に役立ちます。

過去数年にわたって、MVCパターンは再び重要になりましたが、 ASP.NET MVCの出現に関連して、別の理由で。 ASP.NET MVCフレームワークは、ASP.NETとは異なり、ウィジェットの概念を使用しません。 ASP.NETでは、MVCビューはHTMLをレンダリングするASPXコントロールです。 また、コントローラーはHTTP要求を受け入れるため、ユーザーアクションを再度処理します。 httpリクエストに基づいて、何をするかを決定します（モデルを更新するか、特定のビューを表示します）。

モデルビュープレゼンター

ビジュアルプログラミング環境の開発と、ユーザー入力の描画と処理をカプセル化するウィジェットの導入により、個別のコントローラークラスを作成する必要がなくなりました。 しかし、開発者はロジックをプレゼンテーションから分離する必要がありますが、それは今やより高い抽象化レベルでのみです。 複数のユーザー要素からフォームを作成すると、インターフェイスとデータロジックも含まれることが判明したためです。 MVPパターンは、UIをインターフェースロジック（ウィジェットと対話するときに起こること）とデータ（画面に表示するデータ）から分離する方法を説明します。

• モデル
  
  これはアプリケーションのデータであり、それらを取得して保存するロジックです。 多くの場合、データベースまたはWebサービスの結果に基づいています。 場合によっては、ビューで使用する前に、適応、変更、または拡張する必要があります。

  
  
  
  
  
  
  

• 表示する
  
  通常、これはウィジェットを持つフォームです。 ユーザーはその要素を操作できますが、ウィジェットイベントがインターフェイスロジックに触れると、Viewはそれをプレゼンターに向けます。

  
  
  
  
  
  
  
• 発表者
  
  プレゼンターには、すべてのユーザーインターフェイスロジックが含まれ、モデルとプレゼンテーションの同期を担当します。 プレゼンテーションがユーザーが何らかの操作（ボタンのクリックなど）を行ったことをプレゼンターに通知すると、プレゼンターはモデルの更新を決定し、モデルとビューの間のすべての変更を同期します。

プレゼンターがプレゼンテーションと直接通信しないことは重要なことです。 代わりに、インターフェイスを介して通信します。 これにより、プレゼンターとモデルを個別にテストできます。

このパターンには、パッシブビューと監視コントローラーの2つのバリエーションがあります。

パッシブビュー

このバリアントでは、MVPビューはモデルについて何も認識しませんが、代わりに画面に表示する必要があるすべての情報の単純なプロパティを提供します。 プレゼンターはモデルから情報を読み取り、ビューのプロパティを更新します。

これはPassiveViewの例です。

  public PersonalDataView : UserControl, IPersonalDataView { TextBox _firstNameTextBox; public string FirstName { get { return _firstNameTextBox.Value; } set { _firstNameTextBox.Value = value; } } }
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

ご覧のとおり、ビューとプレゼンターの両方で非常に多くのコードを記述する必要があります。 ただし、これにより、それらの間の相互作用がよりテスト可能になります。

スーパーバイザーコントローラー

この実施形態では、ＭＶＰはモデルを認識しており 、データをマッピングに関連付ける役割を果たす。 これにより、プレゼンターとViewの間の通信がより簡潔になりますが、View-Presenter対話のテスト容易性が損なわれます。 個人的には、このパターンに「Controller」という名前が含まれているという事実は嫌いです。 コントローラーはMVCと同じではなく、アプリケーションコントローラーとも同じではないためです。

これは、監督コントローラーパターンの表現の例です。

  public class PersonalDataView : UserControl, IPersonalDataView { protected TextBox _firstNameTextBox; public void SetPersonalData(PersonalData data) { _firstNameTextBox.Value = data.FirstName; } public void UpdatePersonalData(PersonalData data) { data.FirstName = _firstNameTextBox.Value; } }
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

ご覧のとおり、このインターフェースはあまり詳細ではなく、Viewにより多くの責任を負っています。

プレゼンテーションモデル

Martin Fowlerは、Webサイトで、 プレゼンテーションモデルと呼ばれる責任の分離を達成するための別のアプローチについて説明しています。 PresentationModelは、視覚要素に依存しない、ユーザーインターフェイスの論理的なプレゼンテーションです 。

PresentationModelにはいくつかの責任があります。

1. ユーザーインターフェイスロジックが含まれます。
   
   プレゼンターと同様に、PresentationModelにはユーザーインターフェイスロジックが含まれています。 ボタンをクリックすると、このイベントはPresentationModelにルーティングされ、PresentationModelはそれをどう処理するかを決定します。

   
   
   
   
   
   
   

2. 画面に表示するためのモデルからのデータを提供します
   
   PresentationModelは、モデルからのデータを変換して、画面に簡単に表示できるようにします。 多くの場合、モデルに含まれる情報を画面で直接使用することはできません。 最初にデータの変換、補足、またはいくつかのソースからの収集が必要になる場合があります。 これは、モデルを完全に制御できない場合に最もよく起こります。 たとえば、サードパーティのWebサービスまたは既存のアプリケーションのデータベースからデータを受け取った場合。

   
   
   
   
   
   
   
3. UIの状態を保存します
   
   多くの場合、ユーザーインターフェイスには、モデルとは関係のない追加情報を保存する必要があります。 たとえば、画面で現在選択されているアイテムはどれですか？ どの検証エラーが発生しましたか？ PresentationModelは、この情報をプロパティに保存できます。

Viewは、PresentationModelからデータを簡単に取得し、画面に表示するために必要なすべての情報を取得できます。 このアプローチの利点の1つは、視覚要素のテストに依存することなく、UIの論理的で完全にテスト可能な表現を作成できることです。

プレゼンテーションモデルは、Viewがモデル（PresentationModel）からのデータをどのように使用するかを説明しません。

Model-View-ViewModel

最後に、MVVMまたは単にViewModelパターンとも呼ばれるModel-View-ViewModelパターン。 これは、プレゼンテーションモデルパターンに非常に似ています。

実際、おそらく唯一の違いは、WPFとSilverlightのデータバインディング機能の明示的な使用です。 驚くことではないが、 ジョン・ゴスマンは彼のブログでこのパターンに言及した最初の人の一人だったからだ。

ViewModelはViewと直接通信できません。 代わりに、 コマンドの形式で簡単にバインドできるプロパティとメソッドを提供します 。 Viewはこれらのプロパティにバインドして、ViewModelから情報を取得し、その上でコマンド（メソッド）を呼び出すことができます。 これには、ViewがViewModelについて知る必要はありません。 XAML Databindingは、リフレクションを使用してViewとViewModelをバインドします。 したがって、ビューに任意のViewModelを使用して、目的のプロパティを提供できます。

このパターンがSilverlightまたはWPFに適用されるとき、私が本当に気に入っているものは次のとおりです。

• アプリケーションの完全にテスト可能な論理モデルを取得します。

  
  
  
  
  
  
  

• ViewModelはビューに必要なすべての情報を便利な形式で提供するため、プレゼンテーション自体は非常にシンプルになります。 また、デザイナーは、Expression Blendエディターで外観とスタイルを実験し、ユーザーインターフェイスに影響を与えずに変更できます。

  
  
  
  
  
  
  
• そして最後に、Viewのコード （ コードビハインド ）を書くことを避けることができます。 今、これはMVVMパターンのファンの間での論争点です。 個人的には、原則として、Viewに追加のコードを記述する必要はなく、より良い解決策があると思います。 はい、時々、いくつかのトリック（ アタッチされたビヘイビアの作成など）を行う必要がありますが、それらは優れた再利用可能なソリューションを提供します。 ただし、XAMLでのXAMLマークアップとデータバインディングが誰もが好むわけではないことも認識しています。 ViewModelパターンは、 コードビハインドの使用または回避を強制しません。 あなたにとって正しいと思われることをしてください。

おわりに

最も一般的なMV *パターンのこの説明が、それらの違いを理解するのに役立つことを願っています。

翻訳者コメント：



著者と同様に、この説明がMV *パターンの類似点と相違点の理解に役立つことを願っています。 それらを理解すると、アプリケーションにどのパターンを適用するかを簡単に決定できるようになります。



この記事から引き出せる主な結論：

• すべてのパターンのモデルは同じように見え、同じ目標を持っています-データの取得、処理、および保存。
• 従来のMVCでは、ユーザー入力はViewではなくControllerによって処理されます。
• 最新のオペレーティングシステムとウィジェットライブラリはユーザー入力処理を処理するため、MVCパターンのコントローラーは不要になります。
• MV *パターンの目標は、UIマッピング、インターフェースロジック、およびデータ（それらを受信および処理）を互いに分離することです。
• アプリケーションでMV *パターンを使用すると、サポートとテストを簡素化し、データを視覚化された方法から分離できます。
• MVPはかなり普遍的なパターンであり、多くの場合に適しています（これは私の個人的な意見です）。 使用するオプションは、パッシブビューまたは監視コントローラーです。 必要なもの、つまりコードの制御性とテスト容易性、または簡潔さと簡潔さによって導かれます。 タスク間を移動し、1つまたは別のアプローチを適用します。
• システムに自動データバインディング（データバインディング）が適切に実装されている場合、MVVMが選択されます。
• プレゼンテーションモデルはMVVMの優れた代替手段であり、自動リンクがない場合に役立ちます。 ただし、自分でバインディングコードを記述する必要があります（これは単純ですが、日常的なコードです）。 これをエレガントに実装する方法についてのアイデアがありますが、これについては次の記事で説明します。

PS翻訳の準備に協力してくれた同僚のJeevuzにも感謝します 。