MVパターンのWebアプリケーション設計チートシート

インターネットでは、多くの異なる実装とスキーム、すでにほつれたMVCパターンを見つけることができます。 さまざまな本で、さまざまなスキームにも出会った。 これにより、以前の記事「 PHPで名刺サイトを作成する例を使用してMVCパターンを実装する 」に対する混乱とコメントが発生します。 真実を求めて、私はすべてをその場所に置こうとしました...私はデザインパターンに関するいくつかの文献と記事を読み、言及された記事に補遺を書きました。 しかし、フィードバックを期待して別のトピックとして、このアドオンを投稿することにしました。 カットの下には、一般的なMVCおよびMVPスキームがあり、アプリケーションのライフサイクルの説明と、あまり人気のないHMVCおよびMVVMパターンの説明があります。 もちろん、これらのパターンの一部はWebアプリケーションだけでなく、記事ではこの文脈で考慮されています。

MVC

MVCテンプレート（Model-View-ControllerまたはModel-State-Behavior）は、ビジネスロジックをユーザーインターフェイスから分離することを目的とする、アプリケーション構造を構築する簡単な方法を説明しています。 その結果、アプリケーションのスケーリング、テスト、保守が容易になり、もちろん実装されます。


インターネット上の「MVC」のリクエストで、多くの異なるスキームを見つけることができます。 すべてを適切な場所に配置してみましょう。 スキーム1を検討してください：


1.ユーザーがWebリソースを入力すると、初期化スクリプトがアプリケーションのインスタンスを作成し、実行のために起動します。
2.フロントコントローラーのインデックスアクションが実行され、メインページのビューが生成されます。
3.ビューがユーザーに表示されます。

最初の3つのステップは、モデルを使用しない単純なチェーンです。 次は、モデルが関与するシーケンスです。

4.アプリケーションがユーザーからリクエストを受信すると、リクエストされたコントローラーのインスタンスが作成され、指定されたアクションが呼び出されます。
5.このアクションでは、それを変更するモデルのメソッドが呼び出されます。
6.ビューが生成されます（または、ビューにモデルの更新が通知されます）。
7.ビューは表示用のデータを要求します。
8.モデルは要求されたデータを返します。
9.ビューは結果をユーザーに表示します。


このようなスキームもあります-スキーム2：


1.コントローラーはユーザーから次のリクエストを受け取ります。
2.さらに、内部ロジックに応じて：
2a。 ページのプレゼンテーションが形成されます。
2b。 または、モデルのメソッドが呼び出されます。
3.モデルは、変更のビューに通知します。
4.ビューが更新され（モデルがチェーンに含まれていた場合）、ユーザーに表示されます。


一部の図では、ビューからコントローラーへの矢印を見ることができます。 このケースを考慮してください-スキーム3：

1. アプリケーションは、ユーザーから別の要求を受け取ります。要求されたコントローラーのインスタンスを作成し、指定されたアクションを呼び出します。
2. 実際には、何らかの形式のデータ入力を含むビューが生成されます。
3. フォームを含むビューがユーザーに表示されます。
4. ユーザーがフォームに入力して「送信」ボタンをクリックすると、同じコントローラーが呼び出され、フォームから受信したデータをチェックして処理し、別のビューを作成するか、現在のビューを更新します。

実際、ステップ4は、新しいサイクルを初期化する別のステップ1と同等です。したがって、すべてのスキームで、ビューからコントローラーへの方向の暗黙的な接続を想定できます。

MVP

次に、 MVP （Model-View-Presenter）パターン図を見てください-図4：

1. アプリケーションがユーザーからリクエストを受信すると、リクエストされたプレゼンターとアクションが決定されます。 アプリケーションはこのプレゼンターのインスタンスを作成し、アクションメソッドを起動します。
2. アクションメソッドには、データベースからの情報の読み取りなど、モデルの呼び出しが含まれる場合があります。
   
3. モデルはデータを返します。
4. その後、アクションは、モデルから取得したデータが送信されるビューを形成します。
5. 生成されたビューがユーザーに表示されます。

MVPに加えて、 MVVMやHMVCなど、MVCから派生した他のパターンがあります 。

Hmvc

HMVC （Hierarchical Model View Controller）パターンの実装は、 Kohana Webフレームワークで使用されます。 MVCとの主な違いを考慮してください-スキーム5：


アプリケーションは、独立したMVCトライアドの階層を示します。 同時に、各トライアドは他のトライアドのコントローラーに直接接続できます。 このアプローチにより、従来のMVCアーキテクチャを使用してアプリケーションのスケーラビリティの問題を解決し、アプリケーションのさまざまな部分間の依存関係を減らし、コードのさらなるサポートと再利用を促進できます。 このアプローチの利点については、記事「 HMVCを使用したWebアプリケーションのスケーリング 」を参照してください。

MVVM

MVCは、リクエスト/レスポンススクリプトを非常にうまく処理するため、主にWebアプリケーションに定着しました。
このシナリオの主な機能は、ビューの寿命が短いことです。 要求が到着すると、適切なコントローラーに送信され、モデル内のいくつかのプロセスが開始されます。次に、モデルからのデータで満たされ、ブラウザーでクライアントに送信されるビューが作成されます。 1回の実行ですべて。

Ajaxとリッチクライアントサイドアプリケーション（ RIA ）が登場したとき、MVCはページまたはアプリケーション領域での作業にはあまり適していないことが判明しました。これにより、MVP（モデルビュープレゼンター）とMVVM（モデルビューViewModel ） MVCおよびMVPパターンにほとんど精通している人はほとんどいますが、後者について聞いた人はほとんどいません。

MVVMは元々 Silverlight向けに記述されたもので、アプリケーションロジックとは異なる特定のロジックを持つ複雑なインターフェイスに対して利点があります。 MVVMの特徴は、View-Modelレイヤーを介したモデルとビューのより緊密な関係です。これにより、モデル側とビュー側の両方のイベントでデータが同期されます。

MVCでは、ロジックはモデルに配線され、コントローラーに配置することもできますが、これは正しく批判されています（愚かな脂肪コントローラー）。 対照的に、MVVMでは、ロジックはViewModelの「中間」レイヤーに配置されます。 MVVMスキームを検討してください-スキーム6：

実行時に表示されるコンテンツを知らずに、画面の表示領域を決定し、画面に関する最も一般的なデータを設定します。 HTMLの場合、MVVMスキームはDOMのおかげで特に成功しています。ご存知のように、 DOMにはデータが含まれている可能性があります。 したがって、MVVMはKnockOut.JSフレームワークに正常に実装されました。 最初は、すべてが簡単です。 サーバーによって提供されるデータモデルがあります。 DOMの形式で、マークアップの形式で表現があります。 また、ビューの変更を記述し、モデルとビューを接続し、この関係を同期するビューモデル（必要に応じてモデルのビュー）があります。

MVCは多くの場合、アプリケーションの3つのレベルの分離として単に解釈され、それらの間の関係を規制しないことに注意してください。 そのため、多くの場合、モデルとビューが矢印で接続されているダイアグラム（上記の1つがあります）がありますが、この方法では、異なるビューとコントローラーの階層を使用するときに有用なスケーラビリティプロパティが失われることは明らかです。

おわりに

言及されたパターンのどれが優れているかなどの質問に答える必要はありません...主なアイデア-「分割して征服する」だけを作成する必要があります。レイヤーが独立しており、簡単に交換できることが非常に重要です。