web-dev-qa-db-ja.com

MVPおよびMVCパターンの良い例えですか？

正直なところ、私はここの学生ですが、教師から説明の仕方を尋ねる質問がたくさんあり、MVPとMVCのパターンについては見つかりませんでした。

私の問題は、これらのページを調査し、多くのチュートリアルを作成し、例をたどり、それらを使用して学校のプロジェクトでさえ作業したということですが、これらのパターンの本質を把握できない。彼らと何かをしなければならないたびに、私は何かを理解していないためか、理解していないかのように「遅く」なります。

だから私の質問は、MVPとMVCのパターンに、個別に、または比較可能に、適切なアナロジーまたは明確な説明がありますか？

design-patternsmvcmvpanalogy
2
Dragonturtle

同じ基本パターンには、主に3つのバリエーションがあります。

  • Model-View-Controller：それらすべての祖父。もともとSmalltalkで定義されました
  • Model-View-Presenter：主にWindowsフォームアーキテクチャの制限に対処するために作成されたバリアント。 UIがモデルに直接バインドできないテクノロジーに適しています
  • Model-View-View Model：主にMicrosoftのXAMLベースのアプリケーション（WPF、Silverlight、UAP）を処理するために作成されたバリアント。その後、AngularのようないくつかのJavaScriptフレームワークで採用されました。

バリアントを理解するには、元のアーキテクチャパターンと、懸念がどのように分離されているかを理解するのに役立ちます。真実は、3つのバリアントすべてがモデルとビューの両方で一致し、モデルの制御方法が異なるということです。

Model-View-Controller

ModelのSmalltalkの概念は、ドメインモデルと呼ばれるものでした。主な違いは、ドメインモデルには、クライアントのドメイン内で各オブジェクトが実行する必要のあるメソッドも含まれていることです。本質的には、UIのない​​アプリケーションです。

ViewのSmalltalkの概念は、モデルに直接バインドできるものでした。ボタンはメソッドにバインドし、テキストボックスはセッター/ゲッターなどにバインドします。コントローラーと呼ばれるものにもバインドします。

ControllerのSmalltalkの概念は、一般的なアプリケーション向けの機能です。たとえば、「保存」や「読み込み」などのオプションがあるメニュー項目は、モデルを使用してコントローラにバインドされます。 「保存」コントローラは、ドメインルートを取得してディスクなどにシリアル化するオブジェクトです。

WebベースのMVCアプリケーションには、Controllerと呼ばれるものがあり、モデルと対話してビューにバインドするメソッドにURLをマップします。

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

WinForms（Windowsフォームアプリケーション）などには、直接のバインドはありません。 UIには、コンボボックスの値を変更すると、他の場所の状態に影響を与えるいくつかの関数があります。

通常、これ以降のバリアントの場合、モデルはより「データ」モデルになります。つまり、ビジネスオブジェクトのデータを構成するのはプロパティだけです。

Presenterは、インターフェースと実装の組み合わせです。インターフェースはモデルが認識しているものであるため、モデルから発生した変更によりビューを更新できます。実装はビューを認識しており、それと密接に連携します。発生する必要のあるUI関連の変更を処理し、コールバックを使用してモデル自体を更新します。

すべてのビューで常に1つのプレゼンター実装があります。インターフェイスは再利用できますが、通常は再利用できません。

大変な作業なので、ほとんどの人はMVPを使用しません。ただし、WinFormsに基づくアプリケーションをテスト可能にする唯一の方法です。

モデル-ビュー-ビューモデル

XAMLベースのアプリ、およびほとんどのJavaScriptシングルページアプリフレームワークでは、再びモデルに直接バインドするという概念があります。モデルとビューは元のMVCの概念と非常に似ていますが、ほとんどの人は完全なドメインモデルではなく、より単純なデータモデルを使用します。

View Modelは、すべてのビュー固有のプロパティと相互作用を定義し、「Model」と呼ばれるバインド可能なプロパティを通じてモデルを公開します。これにより、モデルはUIの問題を認識できなくなりますが、ビューを必要に応じてインタラクティブにすることができます。ビューは、モデルまたはビュー固有のプロパティに直接バインドできます。

実際には、通常、ビューごとに1つのビューモデルがありますが、理論的には必要ありません。

結論として：

  • MVCがすべてを開始しました。
  • モデルは、3つのバリエーションすべてでビジネスデータとロジックを表します
  • ビューは、3つのバリエーションすべてでユーザーが操作するものを表します
  • 主な違いは、ビューがモデルとどのように相互作用するかです
    • コントローラーはビューに応答し、モデルに基づいて動作します
    • プレゼンターは、モデルと自動的に対話できない場合（バインディングなど）、モデルとビューの間のブリッジとして機能します。
    • ビューモデルは、ビューがバインドしてモデルとそのように相互作用できるビュー固有のモデルのレイヤーを追加します

実際にどちらを使用するかは、使用しているテクノロジーによって実際に決まります。 3つすべてを使用すると、UIを呼び出さずにアプリケーションを徹底的にテストできます。

5
Berin Loritsch