Loading article…
モデル・ビュー・プレゼンター（MVP ）は、モデル・ビュー・コントローラー（MVC）アーキテクチャパターンの派生であり、主にユーザーインターフェースの構築に使用されます。
MVPでは、プレゼンターが「中間者」の機能を担います。MVPでは、すべてのプレゼンテーションロジックがプレゼンターに委ねられます。[ 1 ]
モデル・ビュー・プレゼンター（MVP）ソフトウェアパターンは、1990年代初頭にApple、IBM、Hewlett-Packardの合弁会社であるTaligentで誕生しました。[ 2 ] MVPは、TaligentのC++ベースのCommonPoint環境におけるアプリケーション開発の基盤となるプログラミングモデルです。このパターンは後にTaligentによってJavaに移行され、TaligentのCTOであるMike Potelの論文で普及しました。[ 3 ]
1998年にTaligentが事業を停止した後、Dolphin SmalltalkのAndy BowerとBlair McGlashanはMVPパターンを採用し、Smalltalkユーザーインターフェースフレームワークの基礎を形成しました。[ 4 ] 2006年、Microsoftは.NET FrameworkのユーザーインターフェースプログラミングのドキュメントとサンプルにMVPを組み込み始めました。[ 5 ] [ 6 ]
MVPパターンの進化と複数のバリエーション、MVPとMVCなどの他のデザインパターンとの関係については、 Martin Fowler [ 7 ]の記事とDerek Greer [ 8 ]の記事で詳しく議論されています。
MVPは、自動単体テストを容易にし、プレゼンテーションロジックにおける関心の分離を改善するために設計されたユーザーインターフェースのアーキテクチャパターンです。
通常、ビューの実装では、具体的なプレゼンターオブジェクトをインスタンス化し、自身への参照を提供します。以下のC#コードは、シンプルなビューコンストラクタの例を示しています。
public class Presenter : IPresenter { public Presenter ( IView view ) { // ... } }public class View : IView { private IPresenter _presenter ;public View () { _presenter = new Presenter ( this ); } }ビューで許容されるロジックの程度は、実装によって異なります。極端な例では、ビューは完全に受動的で、すべてのインタラクション操作をプレゼンターに転送します。この構成では、ユーザーがビューのイベントメソッドをトリガーしても、パラメーターも戻り値もないプレゼンターのメソッドを呼び出すだけで、何も起こりません。プレゼンターは、ビューインターフェイスで定義されたメソッドを介してビューからデータを取得します。最後に、プレゼンターはモデルに対して操作を行い、操作の結果でビューを更新します。モデル・ビュー・プレゼンターの他のバージョンでは、特定のインタラクション、イベント、またはコマンドをどのクラスが処理するかについて、ある程度の自由度が与えられます。これは、クライアントのブラウザーで実行されるビューが特定のインタラクションやコマンドを処理するのに最適な場所となる場合が多いWebベースのアーキテクチャに適しています。
階層構造の観点から見ると、プレゼンタークラスは多層アーキテクチャシステムにおけるアプリケーション層に属するものと考えることもできますが、アプリケーション層とユーザーインターフェース層の間に存在する独自のプレゼンター層と見なすこともできます。
.NET環境は、他の開発環境と同様にMVPパターンをサポートしています。同じモデルとプレゼンタークラスを使用して、ASP.NET WebアプリケーションやWindowsフォームアプリケーションなど、複数のインターフェイスをサポートできます。プレゼンターは、インターフェイス（ビュー）コンポーネントからアクセスできるインターフェイスを介して、ビューとの間で情報を取得および設定します。
パターンを手動で実装する以外にも、モデル・ビュー・プレゼンター（MVP）フレームワークを使用することで、MVPパターンをより自動化された方法でサポートできる。
Java（AWT / Swing / SWT ）アプリケーションでは、ユーザーインターフェースクラスにビューインターフェースを実装させることで、MVPパターンを使用できます。
最新のJavaコンポーネントベースのWebフレームワークでは、シッククライアントと同じコンポーネントアプローチを使用してクライアント側のロジックを開発できるため、JavaベースのWebアプリケーションにも同じアプローチを適用できます。
Google Web ToolkitでMVPを実装するには、コンポーネントの一部がビューインターフェースを実装するだけで済みます。VaadinやEcho2 Webフレームワークを使用しても同様のアプローチが可能です。
Javaフレームワークには以下のものが含まれます。
PHPの柔軟な実行環境のおかげで、アプリケーションロジックのアプローチには幅広い可能性が存在します。モデル層の実装は、エンドアプリケーションプログラマに委ねられています。
PHPフレームワークには以下のものが含まれます。