MVC vs MVP vs MVVM: 一般的な Android アーキテクチャ パターンの説明

開発者として働いている間、アーキテクチャ パターンについて聞いたことがあるはずです。 Android の世界で最もよく知られているのは、 MVC 、 MVP 、およびMVVMです。 それぞれの特徴はご存じかと思いますが、違いや使い分けはご存知でしょうか？

これらの質問を自問するなら、この記事はあなたのためのものです。

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

Model-View-Controller (MVC)は、アプリケーションの構造を整理するのに役立つアーキテクチャ パターンです。 モデル、ビュー、コントローラーの 3 つの層に責任を分割します。

Android の専門家が必要ですか?

俺たちと一緒に仕事しようよ！

• モデル– データ レイヤー。ビジネス ロジックの管理と、ネットワークまたはデータベース API のサポートを担当します。 モデルは、リモートおよびローカル データ ソースと連携して、データを取得および保存します。 これは、ビジネス ロジックが処理される場所です。
• ビュー– モデルからユーザーへのデータの視覚化を担当する UI レイヤー。 グラフィカル インターフェイスなど、データの表示方法を管理します。
• コントローラー– ビュー レイヤーとモデル レイヤーを統合する論理レイヤー。 コントローラーの仕事は、ユーザー入力を引き継ぎ、それをどう処理するかを決定することです。

以下の図で、個々のコンポーネントがどのように通信するかをすぐに確認できます。

使い方？

何年にもわたっていくつかの MVC バリアントが登場しましたが、ここでは最も人気のある 2 つのバリアント、パッシブ モデルとアクティブ モデルについて説明します。

パッシブモデル

このバージョンの MVC では、Model を操作するクラスは Controller だけです。 このプロセスをわかりやすく説明するために、次の図を使用します。

1. コントローラーはユーザーのアクションに応答し、モデルに連絡します。
2. モデルが変更されると、コントローラーはビューにデータを更新するように指示します。
3. ビューはモデルから更新されたデータを取得し、それをユーザーに表示します。

アクティブモデル

このバージョンの MVC では、コントローラー以外の他のクラスがモデルを操作します。

この場合、オブザーバー パターンが使用され、ビューはモデル オブザーバーとして登録されます。 これにより、モデルが変更されるとビューが常に更新されます。

利点

1. MVC パターンは、分離の問題を大いにサポートします。 これにより、コードのテスト容易性が向上し、拡張が容易になり、新しい機能を簡単に実装できるようになります。
2. Model クラスには Android システム クラスへの参照がないため、単体テストが非常に簡単になります。
3. コントローラーは、Android クラスを拡張または実装しません。 単体テストが可能になります。

短所

1. ビューは、コントローラーとモデルの両方に関連しています。
   • ビューのモデルへの依存は、主に高度なビューで問題を引き起こします。 なんで？ モデルの役割が生データを提供することである場合、ビューはユーザー インターフェイス ロジックの処理を引き継ぎます。
     一方、モデルが表示用に直接準備されたデータを表示する場合、ビジネス ロジックと UI ロジックの両方をサポートするモデルが得られます。
   • モデルを積極的に実装すると、データ型ごとにオブザーバーが必要になるため、クラスとメソッドの数が指数関数的に増加します。
   • ビューがコントローラーとモデルの両方に依存している場合、UI ロジックを変更すると、いくつかのクラスの更新/変更が必要になる場合があり、パターンの柔軟性が低下します。
2. UI ロジックの処理は、1 つのクラスに限定されません。 新しいプログラマにとって、これはかなりの問題であり、Model、View、および Controller の間で責任が分割される可能性が非常に高くなります。
3. 時間の経過とともに、特に貧血モデルのアプリケーションでは、より多くのコードがコントローラーに送信され始め、コントローラーが肥大化して脆くなります。

概要

ビューがモデルに依存し、ビューにロジックが含まれていると、アプリケーションのコードの品質が大幅に低下する可能性があります。 他のパターン、特にモバイル アプリケーション向けに提案されているパターンを選択することで、この危険性を減らすことができます。 それらについては以下をお読みください。

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

Model-View-Presenter (MVP) は、MVC パターンの弱点に対処するために使用できるアーキテクチャ パターンです。 モジュール性、テスト容易性、およびコードベースの保守がより明確で容易になります。

MVP は、アプリケーション構造をView 、 Model 、およびPresenterレイヤーに分割します。

• モデル– MVC パターンに類似しています。
• ビュー– プレゼンターによって指定された方法でユーザーにデータを提示する役割を担う UI レイヤー。 アクティビティ、フラグメント、または任意の共通ビューで実装できます。
• プレゼンター– ビュー レイヤーとモデル レイヤーの間を仲介するロジック レイヤー。 ビュー層とモデル層の両方に接続し、ユーザーが実行したアクションに反応します。

使い方？

MVPでは、View と Presenter は完全に分離されており、抽象化を通じて相互に通信します。 Contract インターフェイス クラスは、それらの間の関係を定義します。 それらのおかげで、コードがより読みやすくなり、レイヤー間の接続が理解しやすくなります。 実装の詳細に興味がある場合は、Model-View-Presenter: Android ガイドラインをお読みください。

Presenter は Android 固有の API への参照を持つことができないことに注意してください。

個々のコンポーネント間のデータ交換プロセスの概要については、下の図を参照してください。 この記事の目的のために、この例は簡略化されています。

1. ユーザーがアクションを実行します。
2. プレゼンターはユーザーのアクションに反応し、適切なリクエストをモデルに送信します。
3. モデルが更新され、新しいデータがプレゼンターに送信されます。
4. プレゼンターは表示用のデータを準備し、ビューに送信します。
5. ビューは、データをユーザーに表示します。

利点

1. Android 固有のビューや API に関連付けられていないので、Presenter ロジックを簡単にテストできます。
2. ビューとプレゼンターは完全に分離されているため、ビューのモックが簡単になり、単体テストが MVC よりも表面的になります。
3. ビューのプレゼンテーションに関連するすべてを処理するクラスは、Presenter だけです。

短所

1. プレゼンターは、コントローラーと同様に、追加のビジネス ロジックを蓄積する傾向があります。 この問題を解決するには、コードを分解し、責任が 1 つだけのクラスを作成することを忘れないでください。
2. これは Android アプリの優れたパターンですが、小さなアプリやプロトタイプを開発するときは圧倒されることがあります。

概要

MVC と比較すると、このパターンははるかに優れています。 MVC パターンの 2 つの重大な問題を解決します。

1. ビューは、コントローラーとモデルの両方を参照しなくなりました。
2. ビューのプレゼンテーションに関連するすべてを処理するクラスは、Presenter だけです。

MVVM – モデル-ビュー-ビューモデル

Model-View-ViewModel (MVVM) は、イベント ベースのパターンです。 これにより、設計変更にも迅速に対応できます。 このアーキテクチャ パターンにより、MVC や MVP の場合よりもさらに、UI をビジネスおよび動作ロジックから分離することができます。

• ViewModel – モデルからビュー レイヤーへのデータの配信と、ユーザー アクションの処理を扱います。 View のデータ ストリームを提供することは注目に値します。
• ビュー– UI レイヤーは、グラフィカル インターフェイスでのデータ、システム状態、および現在の操作の表示を担当します。 それとは別に、ViewModel を初期化して View 要素にバインドします (ViewModel にユーザー アクションを通知します)。
• モデル– MVC と同じ – 変更なし。

使い方？

MVVMパターンの考え方は、主にViewModelレイヤーで変化するデータを観察し、データ バインディング メカニズムを通じて変更に応答するViewレイヤー (オブザーバー パターン) に基づいています。

MVVM パターンの実装は、さまざまな方法で実現できます。 ただし、データ バインディング メカニズムを含める価値はあります。 これにより、ビュー層のロジックが最小限に抑えられ、コードがより整理され、テストが容易になります。

MVP パターンが、Presenter が View に何を表示するかを直接伝えていたことを意味している場合、 MVVM ViewModelは、View を関連付けることができるイベント ストリームを公開します。 ViewModel は、Presenter の場合のように View への参照を保存する必要がなくなりました。 また、MVP パターンで必要なすべてのインターフェイスが不要になったことも意味します。

ビューは、上の図に示すように、ViewModel にさまざまなアクションも通知します。 したがって、MVVM パターンは、View と ViewModel の間の双方向のデータ バインディングをサポートします。 View には ViewModel への参照がありますが、ViewModel には View に関する情報がありません。

利点

1. ビューに依存していないため、単体テストはより簡単です。 テスト時にモデルが変更されたときに、観測可能な変数が適切に配置されていることを確認するだけで十分です。
2. ViewModel は、単に状態を公開するだけなので、単体テストにさらに適しているため、データがどのように消費されるかをテストせずに個別にテストできます。 つまり、ビューへの依存はありません。
3. View だけが ViewModel への参照を含み、その逆はありません。 これにより、密結合の問題が解決されます。 1 つの View で複数の ViewModel を参照できます。
4. 複雑なビューであっても、同じ階層に異なるビューモデルを含めることができます。

短所

1. 複雑な UI で ViewModel とその状態を管理することは、初心者にとって難しい場合があります。

概要

MVVMは、データ バインディングとイベントベースの通信の利点を利用しながら、MVP によって提供される利点を兼ね備えています。 その結果、モデルが可能な限り多くの操作を制御し、コードの分離とテスト容易性が高いパターンが得られます。

MVC vs MVP vs MVVM: 比較

MVC vs MVP vs MVVM: まとめ

MVP パターンと MVVM パターンはどちらも、MVC パターンよりもはるかに優れています。 どの方法を選択するかは、好みによって異なります。 ただし、この記事でそれらの主な違いを示し、選択が容易になることを願っています.

代替品をお探しですか？

クロスプラットフォームを選択してください！

参考文献:

1. Cervone, S. (2017) Model-View-Presenter: Android ガイドライン。
2. Dang, AT (2020) MVC vs MVP vs MVVM.
3. Muntenescu, F. (2016) Android Architecture Patterns Part 1: Model-View-Controller。
4. Muntenescu, F. (2016) Android Architecture Patterns Part 2: Model-View-Presenter。
5. Muntenescu, F. (2016) Android Architecture Patterns Part 3: Model-View-ViewModel。