MVCパターンとMVPパターンの違い

投稿日: 2022-10-25 2022-10-25
タグ: Architecture, Pattern

1. 概要

このチュートリアルでは、 Model ViewControllerとModelViewPresenterのパターンについて学習します。また、それらの違いについても説明します。

2. デザインパターンとアーキテクチャパターン

2.1. アーキテクチャパターン

アーキテクチャパターンは、ソフトウェアアーキテクチャで一般的に発生する問題に対する一般的な再利用可能なソリューションです。これらはコードベースに大きな影響を与えます。

たとえば、これらはソフトウェアに水平または垂直に影響を与えます。水平方向とは、レイヤー内でコードを構造化する方法を意味します。逆に、垂直とは、リクエストが外側のレイヤーから内側のレイヤーに、そしてその逆に処理される方法を意味します。

より一般的なアーキテクチャパターンには、 MVC 、 MVP 、およびMVVMがあります。

2.2. デザインパターン

デザインパターンは通常、コードレベルの共通性に関連付けられています。これらは、より小さなサブシステムを改良および構築するためのさまざまなスキームを提供します。

さらに、デザインパターンは、エンティティの構造と動作、およびそれらの関係の一部を具体化する中規模の戦術です。一般的に使用されるデザインパターンには、シングルトン、ファクトリー、およびビルダーパターンがあります。

デザインパターンは、スコープがアーキテクチャパターンと異なります。それらはよりローカライズされており、コードベースへの影響は少なくなります。代わりに、コードベースの特定のセクションにのみ影響します。次のセクションでは、これらのパターンを使用する理由について説明します。

3. MVCおよびMVPパターンが選ばれる理由

これらのパターンの使用の背後にある主なアイデアは、関心の分離ビジネスレイヤーとUIレイヤーの間です。これらのパターンは、テストのしやすさなどの機能を提供します。また、データアクセスを隠します。

主要なコンポーネントを分離することで、変更への適応性が高いと言えます。ただし、最大の欠点は、複雑さと学習曲線が追加されることです。

4. MVCパターン

MVCパターンでは、機能は3つの個別の懸念事項に基づいて3つのコンポーネントに分割されます。まず、ビューはUI要素のレンダリングを担当します。次に、コントローラーはUIアクションに応答します。そして、モデルはビジネス行動と状態管理を処理します。

ほとんどの実装では、3つのコンポーネントすべてが互いに直接相互作用できます。ただし、一部の実装では、コントローラーが表示するビューを決定する責任があります。

次の図は、MVCの制御フローを示しています。

このモデルは、ビジネスロジック層全体を表します。ビューは、モデルからフェッチされたデータを表します。さらに、プレゼンテーションロジックを処理します。最後に、コントローラーは制御フローロジックを処理し、モデルを更新します。

MVC は、ビューとモデルを内部でどのように構造化するかを指定しません。通常、ビューレイヤーは単一のクラスで実装されます。

ただし、その場合、いくつかの問題が発生する可能性があります：

ビューとモデルは緊密に結合されています。その結果、ビューの機能要件がモデルに簡単に浸透し、ビジネスロジックレイヤーを汚染する可能性があります
ビューはモノリシックであり、通常はUIフレームワークと緊密に結合します。したがって、ビューの単体テストは困難になります

5. MVPパターン

MVPパターンは、MVCパターンの概念に基づくUIプレゼンテーションパターンです。ただし、システム全体の構成方法は指定されていません。 ビューの構造を指示するだけです。

このパターンは、一般に4つのコンポーネントに責任を分離します。まず、ビューはUI要素のレンダリングを担当します。次に、ビューインターフェイスを使用して、プレゼンターをビューから緩く結合します。

最後に、プレゼンターはビューとモデルと対話し、モデルはビジネスの動作と状態管理を担当します。

一部の実装では、プレゼンターはサービス（コントローラー）レイヤーと対話して、モデルを取得/永続化します。ビューインターフェイスとサービスレイヤーは、プレゼンターとモデルの単体テストの作成を容易にするために一般的に使用されます。

次の図は、MVPの制御フローを示しています。

モデルはMVCと同じで、ビジネスロジックが含まれています。ビューは、データを表示するパッシブインターフェイスです。ユーザーアクションをプレゼンターに送信します。

プレゼンターはモデルとビューの間に座っています。ビジネスロジックをトリガーし、ビューを更新できるようにします。モデルからデータを受け取り、ビューに同じものを表示します。これにより、プレゼンターのテストがはるかに簡単になります。

それでも、MVPにはいくつかの問題があります。

コントローラーはしばしば省略されます。コントローラがないため、制御フローもプレゼンターが処理する必要があります。これにより、プレゼンターはモデルの更新とモデルの提示という2つの懸念事項に責任を持つことになります。
データバインディングを利用することはできません。 UIフレームワークでバインディングが可能な場合は、それを利用してプレゼンターを簡素化する必要があります

6. MVCとMVPの実装

簡単な例でパターンを理解します。表示して更新する必要のある製品があります。これらのアクションは、MVCとMVPで異なる方法で処理されます。

6.1. ビュークラス

製品の詳細を出力する単純なビュークラスがあります。 MVPとMVCの両方のビュークラスは類似しています。

public class ProductView {
    public void printProductDetails(String name, String description, Double price) {
        log.info("Product details:");
        log.info("product Name: " + name);
        log.info("product Description: " + description);
        log.info("product price: " + price);
    }
}

6.2. MVPモデルとプレゼンタークラス

次に、ビジネスロジックのみを担当するMVPのProductクラスを定義しましょう。

public class Product {
    private String name;
    private String description;
    private Double price;
    
   //getters & setters
}

MVPのプレゼンタークラスは、モデルからデータをフェッチし、それをビューに渡します。

public class ProductPresenter {
    private final Product product;
    private final ProductView view;
    
     //getters,setters & constructor
    
    public void showProduct() {
        productView.printProductDetails(product.getName(), product.getDescription(), product.getPrice());
    }
}

6.3. MVCモデルクラス

MVCの場合の違いは、ビューがMVPのプレゼンタークラスではなくモデルクラスからデータを取得することです。

MVCのモデルクラスを定義できます。

public class Product {
    private String name;
    private String description;
    private Double price;
    private ProductView view;
    
    //getters,setters
    
    public void showProduct() {
        view.printProductDetails(name, description, price);
    }
}

showProduct（）メソッドに注意してください。このメソッドは、モデルからビューに渡されるデータを処理します。 MVPでは、これはプレゼンタークラスで実行され、MVCではモデルクラスで実行されます。

7. MVCとMVPの比較

MVCとMVPの間に大きな違いはありません。どちらのパターンも、複数のコンポーネント間で責任を分離することに重点を置いているため、UI（ビュー）とビジネスレイヤー（モデル）の緩い結合を促進します。

主な違いは、パターンの実装方法といくつかの高度なシナリオです。 主な違いのいくつかを見てみましょう。

結合：ビューとモデルはMVCで緊密に結合されていますが、MVPでは緩く結合されています
通信：MVPでは、View-PresenterとPresenter-Model間の通信はインターフェースを介して行われます。ただし、コントローラーとビューレイヤーはMVCの同じアクティビティ/フラグメントに分類されます
ユーザー入力： MVCでは、u ser入力は、モデルに以降の操作を指示する Controllerによって処理されます。ただし、MVPのでは、ユーザー入力はビューによって処理され、プレゼンターに適切な関数を呼び出すように指示します。
関係のタイプ：A多対1関係コントローラーとビューの間に存在します。 1つのコントローラーは、MVCで必要な操作に基づいてさまざまなビューを選択できます。一方、プレゼンターとビューはMVPで1対1の関係にあり、1つのプレゼンタークラスが一度に1つのビューを管理します。
主成分：MVCでは、コントローラーが担当します。適切なビューを作成し、ユーザーの要求に応じてモデルと対話します。逆に、MVPではビューが担当します。モデルをさらに指示するプレゼンターのビュー呼び出しメソッド
単体テスト：密結合のため、MVCは単体テストのサポートが制限されています。一方、ユニットテストはMVPで十分にサポートされています

8. MVPがMVCよりも優れている理由

MVPは、アプリケーションをモジュールに分割できるという点で、MVCよりもわずかに優れています。したがって、ビューを絶えず作成する必要がなくなります。言い換えれば、MVPはビューを再利用可能にするのに役立ちます。

9. 結論

このチュートリアルでは、MVCとMVPのアーキテクチャパターンとそれらの比較を見てきました。

サンプルコードは、GitHubでから入手できます。

getdocs

13036