MVP vs MVC vs MVVM vsVIPER。 iOS開発には何が良いですか？

公開: 2021-10-05

すべての家が堅固な基盤を持ち、すべてのソフトウェアプロジェクトが構築されているソフトウェアアーキテクチャを持ち、各プロジェクトが独自のアプリ構造を持っているのと同じです。 アーキテクチャパターンの種類はさまざまですが、最も一般的に使用されるものは4つあります。ITの世界全体が絶えず批判しているものの、同時に使用し続けているものです。MVC、MVP、MVVM、Viper （ほとんどがiOSアーキテクチャパターンとして最後のもの） 。 これらのパターンの比較と、Swiftで作成された各プロジェクトのケースにより適したものの選択については、この記事でさらに詳しく説明します。

時系列に沿って、最初のソフトウェアデザインパターンが出現すると、それらのios開発アーキテクチャパターンの一般的な問題が到着するのにそれほど時間はかかりませんでした。

たとえば、サーバーとクライアントの通信の問題-ある人が別の人とどのように相互作用するのでしょうか？ または別の問題-アプリケーションのビジネスロジックをアプリ内のロジックから分離する問題。 これは、アプリケーションのアーキテクチャの観点からどのように機能する必要がありますか？ それらのために、さまざまなアーキテクチャ層のさまざまなデザインパターンが世界を見てきました。 それらの中で最もよく知られているのは次のとおりです。

-シングルトンデザインパターン。

このパターンでは、1つのクラスを1つのオブジェクトにのみ適用できます。このオプションは、限られた数のインスタンス（または1つのインスタンスのみ）がシステムによって承認される場合に役立ちます。

-デコレータデザインパターン。

シングルトンとは対照的に、このパターン（アダプターパターンと一緒にラッパーと呼ばれることもあります）では、特定の動作を単一のオブジェクトに（静的または動的に）追加できます。これらすべては、他のオブジェクトの動作に影響を与えることなく、 1つはクラスを共有します。

-ブリッジデザインパターン。

「DesignPatterns」という本の著者である悪名高いGangof Fourによって最初に紹介されたこのアーキテクチャパターンは、「カプセル化と集約を使用し、継承を使用して責任を異なるクラスに分離できます。クラスが頻繁に存在する場合、オブジェクト指向の機能プログラムのコードへの変更は、プログラムに関する最小限の事前知識で簡単に行えるため、プログラミングは非常に便利になります。 ［ソース：ウィキ］

これらのパターンはかなり異なりますが、コードライターの一般的な問題はそれぞれで発生しています。 たとえば、シングルトンの「質量」を使用します。 シングルトンはグローバルすぎます。コードの依存関係は、インターフェイスに公開されるのではなく、アプリケーション内に深く隠されているためです。 そのため、ソフトウェア開発プロセス中に新しいパターンが絶えず出現します。

最も一般的に使用される4つのパターンは、 MVC、MVP、MVVM、およびVIPER （主にiOSの場合）です。

記載されているのと同じ順序で開発されたものはすべて、独自の利点と欠点があり、それぞれをどこに適用するかについて多くの論争を引き起こしています。 彼らが実装するベストプラクティスにもう少し注意を払うことは、物事を少しクリアするかもしれません。

MVCパターン

MVCスキーム

すべてのソフトウェアパターンの祖父は、1970年代初頭にノルウェーのコンピューター科学者Trygve Reenskaugによって最初に導入されました。モジュール-ビュー-コントローラーは、MVCとして広く知られていますが、オブジェクト指向プログラミングの最初のパターンアプローチの1つです。

ビュー部分は、システムのユーザー（モバイルまたはWebアプリのインターフェースなど）のすべてを表示する役割を果たします。 モデルは通常、データベース、ビジネスエンティティ、およびその他のデータを担当します。 次に、コントローラーはモデルの作業、データベースに提供されるデータ、言及されたデータベースからビュー部分への表示、およびその逆を調整します。

MVCモデルが普遍的であるとしても、2つの最大の競合相手であるAppleとGoogleには、モデル-ビュー-コントローラーシステムを表す独自のパターンがあります。 Appleのシステムの問題は、ViewとControllerのパーツ間の緊密な接続にあり、ViewとControllerを統合し、Modelのパーツを分離したままにするという点でほぼ緊密です。

その結果、テストプロセスが不十分になります。モデルのみを検査でき、V＆C（接続が緊密であるため）はまったくテストできません。

ControllerセグメントとViewセグメントの間の堅牢な接続は、ソフトウェアに関しては本当に「不健全」であることが証明されたため、新しいパターンがすぐに世界に現れました。

MVPパターン。

MVPスキーム

私たちの多くは、Minimum Viable Productのコンテキストでこのショートカットを聞いたことがありますが、ソフトウェアエンジニアリングの観点からは、別の意味があります。 Model View Presenterパターンにはいくつかの重要なポイントがあり、MVCとの間に大きな隔たりがあります。

MVPモデル

  • ビューは、モデルとより緩く結合されています。 プレゼンターは、モデルをビューにバインドする責任があります。

  • ビューとの対話はインターフェースを介して行われるため、単体テストが容易になります。

  • 通常、プレゼンターに表示= 1対1でマップします。 複雑なビューには複数のプレゼンターがいる場合があります。

MVCパターン

  • コントローラーは動作に基づいており、ビュー間で共有できます

  • 表示するビューを決定する責任があります
    ［ソース：インフラジスティックス］

この配置では、モデルの機能は同じままです。 プレゼンターは、それぞれビジネスロジックを担当します。 V部分は、特に興味深いものです。これは、相互作用の権限を持つViewとViewControllerの2つの部分に分割されているためです。 MVVMとMVCの質問がある場合、このタイプのシステムは、MVCパターンで使用されていた「重い依存症」のビューモードとコントローラーモードの問題を解決します。

この場合、モデル、ユーザーインタラクションを使用したビュー、プレゼンターパーツなど、テストの障害も解決されます。これらはすべてテストできます。
まだ存在する不便さはプレゼンターの側にあります-それでもあまりにも大規模ですが、それでも既存のビジネスロジックのすべてを考慮に入れています。 そのため、次のアクトが登場しました…

MVVMパターン

MVVMモデル

Model-View-ViewModelソフトウェアアーキテクチャパターンは、Microsoftのアーキテクトの1人であるJohnGossmanによって2005年に作成されました。 MVVMモデルの3つのコアコンポーネントはそれぞれ次のとおりです。
モデルは、「ビジネスおよび検証ロジックとともにデータモデルを含むアプリケーションのドメインモデルの実装です。 モデルオブジェクトの例には、リポジトリ、ビジネスオブジェクト、データ転送オブジェクト（DTO）、Plain Old CLRオブジェクト（POCO）、生成されたエンティティオブジェクトとプロキシオブジェクトが含まれます。」 ［ソース：マイクロソフト］

ビューは、ユーザーが見ることができるすべてのものです。つまり、画面上のすべてのレイアウト、構造、外観です。 基本的に、アプリケーション内ではアプリのページになります。 Viewは、このパーツとModel自体の間のすべての通信を除いて、ViewModelのみに更新を取得および送信します。

ViewModelは、ViewシステムコンポーネントとModelシステムコンポーネント間の「相互接続チェーン」であると想定されており、その主な機能は、Viewのロジックを処理することです。 通常、ビューモデルは、モデルクラスのメソッドを呼び出すことによってモデルと対話します。 次に、ビューモデルは、Microsoftが述べているように、ビューが簡単に使用できる形式でモデルからのデータを提供します。

MVCとiOSMVVMの主な違いは、MVVMの分散パターンが以前にリストされたMVCよりも優れていることですが、MVPと比較すると、非常に過負荷になっています。 ここでは、テストが特に重要です。コードを簡単に記述している間は、プロジェクト全体が適切に機能することを保証できないためです。テストは、明るい点で、機能することを確認するのに役立ちます。

次のアーキテクチャパターンの進化は最近リリースされ、現在では最も新しいソフトウェアアーキテクチャアプローチです。

iOSVIPERアーキテクチャ

VIPERパターン

提供するのに最適なアーキテクチャソリューションを探していた世界中のiOS開発者は、クリーンコーダーでボブおじさんによって導入されたいわゆる「クリーンアーキテクチャ」アプローチにぶつかりました。これは、世界中のソフトウェア専門家にトレーニングセッションを提供する有名なプラットフォームです。

Clean Architectureは、アプリケーションの論理構造をいくつかの責任レベルに分割します。 次に、この「分離」により、緊密な依存関係の問題が解決され、すべてのレベルのテストの可用性が向上します。

iOS開発用のVIPER

VIPERは、iOSで構築されたアプリケーション向けのクリーンアーキテクチャを実現したものです。 すべてのパターンの名前に共通のルールとして、ビュー、インタラクター、プレゼンター、エンティティ、およびルーティングのバックロニムでもあります。 VIPERの各パーツは、特定の要素、特に次の要素を担当します。

  1. ビューは、ユーザーがインターフェースで行うアクションをミラーリングする責任があります

  2. VIPERパターン内でのプレゼンターの責任は非常に限られています。エンティティから更新を受信しますが、データを送信しません。

  3. インタラクターは、実際にエンティティに対応するシステムの部分です。 このスキームは次の方向で機能します。PresenterはViewモデルの変更についてInteractorに通知し、InteractorはEntityパーツに接続し、Entity Interactorから受信したデータを使用して、Viewにユーザー用にミラーリングするように命令するPresenterに戻ります。 すべてのデータモデル、すべてのエンティティ、およびすべてのWebサイトは、Interactorパーツに接続されています。

  4. エンティティは、Interactorによって制御されるオブジェクト（タイトル、コンテンツなど）で構成されます。エンティティは、I-partを介してのみ、Presenterと直接対話することはありません。

  5. ルーティング（またはワイヤーフレームと呼ばれることもあります）は、すべての画面間のナビゲーションを担当し、基本的にはルーティングを担当します。 ワイヤーフレームは、UIWindow、UINavigationControllerなどのオブジェクトを制御します。

特にiOSアーキテクチャシステム内では、すべてUIkitと呼ばれるフレームワークに基づいて構築されています。このフレームワークには、Apple MVCのすべてのコンポーネントが含まれていますが、以前はコーダーを狂わせていた緊密な接続はありません。

VIPERモジュールは、単体テストに関しても同様に有益です。優れたパターンのディストリビューションにより、利用可能なすべての機能をテストできるからです。 多くの点で、これは開発者が以前のMVC、MVP、およびMVVMソフトウェアパターンで直面した主な問題でした。

それをすべて戴冠させる。

これら4つのソフトウェアデザインパターンはすべて、iOS開発に最適なアーキテクチャパターンの1つと呼ばれることがよくありますが、それらはすべて理想的とは言えず、開発するすべてのプロジェクトで普遍的に使用されているわけではありません。 悲観的な側面として、各パターンにある問題の短いリストを次に示します。

  • MVC、MVP、MVVM-これらすべてにこの「緊密な接続」の問題があり、開発に更新を導入し、後でそれらをテストすることは非常に困難な作業です。

  • VIPER vs MVVM、MVCまたはMVPは、勝利のケースであると考えられています。 その高い柔軟性と優れた妥当性にもかかわらず、生成するのが難しい多くのニュアンスもあります。

100％固溶体はありますか？ 実際にはそうではありませんが、プロジェクトごとに、これら4つのiOSアプリパターンのいずれかがまさに必要なものである可能性があります。 そうでない場合は、2つの混合物になります。 または多分3つ。 フォーチュンは大胆さを好むと言われているので、ソフトウェアデザインパターンを大胆に試してみませんか？

マックスマシュコフとエリナベッサラボワによって書かれました。