MVCの問題
理論的には完璧に見えますが、MVCは実際には多くの課題に直面しています。 まず、解決すべき主な問題を覚えておきましょう。アプリケーションを3つの異なる側面（コントローラー、ビュー、モデル）に分割し、それらの間、およびアプリケーションのさまざまな部分間の依存を最小限に抑えます。 教科書の例では、これは大丈夫です。 何かのモデル、データを表示するビュー、ユーザーのアクションに応じてアクションを実行するコントローラーがあります。
問題1
実際には、通常、記事、ユーザー、コメントなど、複数のモデルを同時に操作する必要があります。 原則として、これは重要ではありません。MVCパターンはこれを提供しますが、依存関係の数を増やします。ビューとコントローラーは複数のモデルに依存し、複数のビューとコントローラーは1つのモデルに依存します。
第二の問題
異なるモデルのデータを表示するには、それらのモデル専用に作成されたビューを使用します。 たとえば、記事と製品で同じようにコメントを表示するのは論理的なようです。 この従来のMVCは提供していませんが、テンプレートの使用によりこれは部分的にバイパスされています。 つまり モデルからデータを受け取る1つのビューが使用され、複数のテンプレートの組み合わせが表示を表示するために使用されます。 また、依存関係の数が増加します。
問題3
1つのモデルではなく、同時に複数のモデルでアクションを実行する必要がある場合があります。 たとえば、ユーザーを削除する場合、そのユーザーの記事とコメントをすべて削除する必要があります。 そのため、関連するモデル（この例ではユーザー）だけでなく、直接関連しないモデルの操作を記述するコントローラーを作成する必要があります。 したがって、非自明の依存関係が表示されます。
HMVCの基本的な考え方
これらの問題を修正する方法は？ MVCの代わりにMMMVVVCCのようなものが判明するという事実のために問題が発生するため、各モデルタイプとコントローラーは異なるサブシステムに属することができるため、答えは明らかです-モデル、タイプ、コントローラーが1つしかないMVCに戻ります。
したがって、HMVCの最初の原則：アプリケーションは、コントローラを介してサブシステムの残りと排他的に相互作用する、厳密に固定されたモデルビューコントローラートライアドのみを使用します。
これから2番目の原則が浮かび上がります。より複雑な組み合わせを整理するために、トライアド階層が使用されます。
一見、HMVCを実装できるように思えるかもしれませんが、別のコントローラーからコントローラーを呼び出すだけで十分です。 ただし、Webアプリケーションでは、動作はコントローラーに渡されるコマンドだけでなく、httpリクエスト全体にも依存します。 モデルとビュー自体の両方がリクエストを分析し、何らかの方法でその動作を変更できます。 したがって、要求を別のコントローラーに転送する機能が必要であり、必ずしも受信したものと同じではありません。 これは、3つの異なる方法で実行できます。
HMVCクライアントサーバー
httpリクエストを送信する最も簡単な方法は、これにブラウザーを使用することです。 この場合、フレームワークによる特別なサポートさえ必要ありません。 そして、このアプローチはどこでも使用されます-AJAXと呼ばれます。 はい、それはajaxです。 1つの基本的なトライアドモデルビューコントローラーを使用して、ページのメインコンテンツ（記事のテキストなど）を表示し、同じトライアドへのajaxリクエストを使用して、残りの必要なフラグメント（コメントなど）を受け取ります。
このアプローチにより、ページの一部（ブラウザ、プロキシサーバー、またはプロキシhttp-serverのキャッシュにデータをキャッシュ）でhttpキャッシュを使用し、リアルタイムモードで一部をダウンロードできます。 たとえば、記事ページは次のように部分的にロードできます。
- 記事自体のテキストを含むページは静的であり、可能であれば、ブラウザキャッシュから削除されます。キャッシュはかなり長期間保存できます。
- コメントは常に更新されるため、キャッシュされず、Webサーバーから毎回要求されます。
- 最新のニュースブロックは随時更新され、キャッシュから取得できますが、記事が保存されている限りキャッシュに保存されません。
長所：
- フレームワークのサポートは必要ありません（フレームワークなしでも実行できます）。
- 柔軟なhttpキャッシュ
- 別のWebサーバーに要求を送信し、複数のサーバー間で負荷を分散する機能。
短所：
- Javaスクリプトを記述する必要があります。
- ブラウザからサーバーへのリクエストの数が増加し、ページの読み込み時間が長くなり、Webサーバーの負荷が増加する可能性があります。
サーバー間HMVC
次に簡単な実装は、Webサーバーからそれ自体にリクエストを送信することです。 このために、curlを使用するか、http要求を送信できる別のライブラリを使用できます。 このアプローチは前のアプローチと似ていますが、リクエストはユーザーのブラウザではなく、ドキュメントの生成プロセスでWebサーバー自体によって送信されるという違いがあります。
例として、再度解説を検討してください。 このページは記事に基づいているため、記事のコントローラー、ビュー、モデルを使用して表示します。 ただし、クラシックMVCがモデルとコメントタイプを使用して記事ビュー内にコメントを表示する場合、HTMVはコメントコントローラーにリクエストを送信します。 この場合、並列プロセスの起動を開始するhttp要求により、記事に対する既製のコメントブロックが生成されます。
前のケースと同様に、このアプローチではhttp-cachingを使用できますが、使用するにはプロキシhttp-server、たとえばnginxを使用する必要があります。
長所：
- クライアントには完成したページが提供されます。
- 柔軟なhttpキャッシュ
- 別のWebサーバーに要求を送信し、複数のサーバー間で負荷を分散する機能。
短所：
- 1つのページを作成するために、いくつかの並列プロセスが起動され、Webサーバーの負荷が増加します。
サーバー内HMVC
「サーバー内」という用語は、すべてがWebアプリケーションプロセス内で発生することを意味します。 前のケースと同様に、model-view-controllerトライアドはリクエストを介して相互に通信し、通常のhttpリクエストと同じ方法でそれらによって認識される必要がありますが、これらのリクエストの転送はフレームワークを提供します。 プログラマーの観点からは、最後の2つのオプションに大きな違いはありません。 適切なフレームワークでは、違いは1つのパラメーターのみである必要があります。これは、サブクエリが内部（プロセス内）であるか、外部（実際のhttp要求が原因）であるかを示します。
長所：
- Webアプリケーションのインスタンスを並行して実行する必要はありません。
短所：
- HTTPキャッシュを使用する方法はありません。
HMVCアプリケーションのスケーリング
Webリソースの人気が非常に高くなると、1つのサーバーでは十分ではないという疑問が生じる場合があります。 そして、複数のサーバー間の負荷分散の問題が生じます。 負荷をすばやく分散する最も簡単なオプションは、リソースとデータベースの複製の複数のコピーを使用することです。 ただし、HMVCを使用すると、別の方法でサーバー間でタスクを分散できます。 たとえば、1つのサーバーが記事、1つのユーザープロファイル、および3番目のコメントを管理します。 モジュールを十分に分離する場合、これを迅速に実装するには、適切な要求でそれらが外部にあることを登録し、処理するサーバーのアドレスを示すだけで十分です。
最後に
実際のWebアプリケーションの作成は、HMVC実装オプションのいずれかに限定する必要はありません。 いずれの場合も、彼に最適なものを選択できます。 また、一般的なオプション「サーバーサーバー」と「イントラサーバー」は「外出先」で切り替えることができます。