「MVP」アーキテクチャとは？
インターネットが普及したことで、ソフトウェアベンダーは簡単にアップデートプログラムを提供できるようになり、その一方で開発側はソースコードを頻繁に修正、変更する必要性が出てきました。そこで「ソースコードの変更耐性」という新たな課題が生まれました。これを解決するアーキテクチャとして生まれたのが「MVP」（Model／View／Presenter)です。「MVP」は異なる複数のViewを同時にサポートするために生み出されたもので、Viewとの独立性が非常に高いアーキテクチャです。
MVCアーキテクチャはModelにデータ変更が加わった場合、直接Viewに通知し変更を加えますが、MVPではPresenterが変更通知をとりまとめViewに通知するというものです。MVCはModelとViewがつながっていますが、MVPはPresenterを介する形となるためModelとViewは完全に分離されています。これは、ModelとViewが直接つながらずControllerを介して変更が通知されるMVCの発展形である「MVC2」に近いアーキテクチャです。
MVPアーキテクチャの大きな特長は、ビジネスロジックに関連する機能をPresenterに集約することで、Modelの簡素化とViewの独立性を実現したことにあります。
こうしてModelとViewの独立性が高まることによって、各モジュールの変更が他のモジュールに及ぼす影響を最小限にでき、その結果として「変更に強いアーキテクチャ」を実現しました。また、MVPは、多くのアプリ開発の現場で活用されており、ベストプラクティスが集まっている点もメリットです。
また、以上のようなメリットに加えてGoogleがMVPベースのサンプルアプリを多く提供し、「Android Support Library」も充実しており、簡単にAndroidのアプリ開発を始められるため、モバイル開発の現場では、Androidアプリの開発にMVPを採用する実例が多いようです。Androidアプリ開発では、MVPは候補に挙げておくべきアーキテクチャだと思います。
「テスタビリティー」から考えるMVPアーキテクチャ
MVPをテスタビリティーの観点から考えると、MVCでModelに含まれていたビジネスロジックに関わる機能をPresenter側に集約したことで、Modelを単体でテストしやすくなり、さらに、Viewの独立性が高いアーキテクチャのため、Viewの単体テストもしやすくなりました。
その半面、Presenterにビジネスロジックが集中するため、いかにPresenterの機能を細かく分離してテストをしやすいように実装できるかが、大きなポイントだと考えられます。また、View／Presenter／Modelが1セットとして実装されることが多いため、規模が大きなソフトウェアやアプリケーションの場合、この組み合わせの数が膨大になりがちです。この問題については、次回以降で説明したいと思います。以上のポイントを踏まえ、MVPの特長をまとめると以下になります。
MVPの特長まとめ
- 「変更に強い」アーキテクチャである
- 3つの基準「コード量」「変更への耐性」「テストのしやすさ」全てが平均的なバランス
- モバイルアプリケーション、特にAndroidアプリ開発の現場での採用例が多い
