MVC、MVP、MVVM: どれを選ぶべきか?

MVC、MVP、MVVM: どれを選ぶべきか?

現代のアプリケーションは非常に多様な機能を必要とするため、それらの開発プロセスはサイズと複雑さが増しています。これを支援するために、アーキテクチャ デザイン パターンを使用できます。これらは、テストと保守が容易なアプリケーションの構築をサポートします。





最も一般的な 3 つの設計パターンは、MVC、MVP、および MVVM です。 MVC はモデル、ビュー、およびコントローラーを表し、MVP はモデル、ビュー、およびプレゼンターを表し、MVVM はモデル、ビュー、およびビュー モデルを表します。





アーキテクチャと設計パターン

建築パターン

アーキテクチャ パターンは、ソフトウェア アーキテクチャのいくつかの重要なコンポーネントを明確にし、定義します。建築のパターンはシステムのイメージを伝えますが、 それはアーキテクチャではありません .実際、これは、特定のコンテキストでソフトウェア アーキテクチャで一般的に発生する問題に対する一般的で再利用可能なソリューションです。





デザインパターン

設計パターンは、アプリケーションまたはシステムを設計する際の一般的な問題を解決するために使用できる形式化されたベスト プラクティスです。

アーキテクチャ パターンとデザイン パターンの違い

一般的な用語であるパターンから始めましょう。ソフトウェアでは、パターンとは、巨大で複雑な構造をより小さく単純なコンポーネントに分解できる反復プロパティです。このパターンを使用して、問題のクラスに対する一般的な解決策を作成できます。



ソフトウェア開発の各レベルでは、さまざまなツールを使用します。より小さなレベルでは、これらのツールはデザイン パターンです。アーキテクチャ パターンはより大きなレベルで存在し、 プログラミングパラダイム 実装レベルで。

私の電話がハッキングされているかどうかを知る方法

なぜ建築設計パターンが必要なのか?

ソフトウェア開発中に、アーキテクチャ設計パターンを使用して一般的な問題を解決できます。優れたアーキテクチャは、次のことにも役立ちます。





  • 複雑なタスクをより単純なタスクに分割します。
  • バグを減らします。
  • テスト可能で保守可能なコードを生成します。

ただし、アーキテクチャ パターンがないと、アプリのビジネス ロジックを維持するのが困難になる可能性があります。

モデル、ビュー、ビューモデル、コントローラー、プレゼンター

各パターンを見る前に、パターンを構成する用語を次に示します。





  • モデル データを保存し、データベースと直接通信します。モデルは、データとアプリケーション ロジックを表す部分です。データの処理、変更、または処理を管理するビジネス ルールを定義します。
  • 意見 モデルのデータを表示し、ユーザー インターフェイスでのデータの表現を担当します。
  • ビューモデル MVVM パターン専用です。これはビュー レイヤーの抽象化であり、モデル データのラッパーとしても機能します。
  • コントローラ ビューとモデルを統合するコンポーネントです。
  • プレゼンター MVP モデルにのみ存在するコンポーネントです。プレゼンターはビュー コンポーネントから入力を取得し、モデルを使用してデータを処理します。

MVC、MVP、および MVVM パターン

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

の MVC アーキテクチャ パターン が最初で、今日では Web アプリケーションの分野で人気があります。 1970年代に導入されました。このパターンを使用すると、関心の分離 (SoC) を中心にアプリケーションを構築できます。アプリケーションのテスト、保守、および開発に必要な労力が軽減されます。

Windowsはフォーマットを完了できませんでした

MVC パターンでは、モデルはビューまたはコントローラーを理解していません。モデルのオブザーバーは、ビューとコントローラーに変更があるたびにアラートを受け取ります。コントローラーは、ルーティング プロセスがモデルを関連するビューに接続するのに役立ちます。

MVC パターンの利点のいくつかは次のとおりです。

  • 関心の分離 (より集中)。
  • コードのテストと管理が容易になります。
  • アプリケーションのレイヤーの分離を促進します。
  • コードの編成と再利用性が向上します。

MVC の仕組みは次のとおりです。

  MVC の仕組みを示す図の画像

SoC のおかげで、MVC はコード サイズを縮小し、クリーンで管理しやすい優れたコードを作成できます。

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

MVP パターンは、モデルとビューという 2 つのコンポーネントを MVC と共有します。コントローラーをプレゼンターに置き換えます。プレゼンターは、その名前が示すように、何かを提示するために使用されます。これにより、ビューをより簡単にモックできます。

MVP では、すべてのプレゼンテーション ロジックがプレゼンターにプッシュされるため、プレゼンターは「仲介者」の機能を備えています。 MVP のビューとプレゼンターも互いに独立しており、インターフェイスを介して対話します。

以下は、MVP パターンがどのように機能するかを示した図です。

  MVP の仕組みを示す図の画像

プレゼンターは、ビューを介してユーザーから入力を受け取ります。次に、モデルを使用してユーザーのアクションを処理し、結果をビューに返します。プレゼンターは、インターフェイスを介してビューと通信します。

Model-View-ViewModel パターン

MVVM は、MVC の最新の進化形です。 MVVM の主な目的は、ドメイン ロジックとプレゼンテーション層を明確に分離することです。 MVVM は、ビューとビューモデル間の双方向のデータ バインディングをサポートしています。

MVVM パターンを使用すると、コードのビューとモデルを分離できます。これは、モデルが変更されたときにビューを変更する必要がないことを意味し、その逆も同様です。ビューモデルを使用すると、単体テストを実行し、ビューを使用せずにロジックの動作をテストできます。

MVVM の仕組みを次の図に示します。

  MVVM の仕組みを示す図の画像

MVC、MVP、および MVVM をいつ使用するか

各パターンについて学習したので、いつそれらを使用するかを調べてください。

ラムを混ぜて合わせることができますか

MVC を使用する場合

MVC は単に関心の分離の実装です。アプリケーションでデータ (モデル)、データ処理 (コントローラー)、およびデータ表示 (ビュー) を分離する必要がある場合は、MVC が適切に機能します。 MVC は、データ ソースやデータ プレゼンテーションがいつでも変更される可能性があるアプリケーションにも適しています。

MVP を使用する場合

アプリケーションに双方向フローがある場合、MVP を使用できます。ユーザーの操作でモデルから何かを要求する必要があり、この要求の結果によって UI がすぐに変更される場合は、MVP を検討してください。

MVVM を使用する場合

次の場合に MVVM を使用します。

  • プロジェクトをデザイナーと共有する必要があり、デザインと開発の作業は独立して行うことができます。
  • ソリューションの単体テストが必要です。
  • 組織内のプロジェクト内およびプロジェクト間で、再利用可能なコンポーネントが必要です。
  • コード ベース内の他のロジックをリファクタリングすることなく、ビューをより柔軟に変更したい。

どのパターンを選ぶべきですか?

設計パターンを使用する主な理由は、複雑さを軽減することです。これは、全体的な複雑さを軽減するか、なじみのない複雑さを慣れ親しんだものに置き換えることで実現できます。設計パターンがこれら 2 つの方法のいずれかで複雑さを軽減できない場合は、いずれも使用しないでください。それは何の価値も追加しません。

デザイン パターンを使用する必要があると確信している場合は、チェックリストを作成してみてください。ここで見た状況に基づいて、プロジェクトに最適なものを選択してください。