HMVCパターンとは何ですか？
Kohanaのドキュメントを読んで、3.0バージョンの主な違いは、バージョン2.xのようにMVCではなくHMVCパターンに従うことです。 KohanaのドキュメントとWikipediaのドキュメントにあるこのページは、明確なアイデアを本当に与えてくれませんでした。
質問：HMVCパターンとは何ですか？MVCとはどう違いますか？
Sam de Freyssinet（Kohana開発者の1人）は、むしろ HMVCについての詳細な記事 、それが何で、どのように使用できるかを書いています。
リンクは死んでいます：新しいリンク- https://web.archive.org/web/20160214073806/http://techportal.inviqa.com/2010/02/22/ scaling-web-applications-with-hmvc /
私は現在、独自のPHP 5.3 HMVCフレームワークと呼ばれるAlloyを開発中です。 。私はHMVCに多大な投資と販売を行っているため、別の視点を提供し、おそらくHMVCを使用する必要がある理由と、それがもたらすメリットをより適切に説明できると考えました。
HMVCアーキテクチャを使用することの最大の実際的な利点は、コンテンツ構造の「ウィジェット化」です。例としては、コメント、評価、TwitterまたはブログのRSSフィード表示、またはeコマースWebサイトのショッピングカートコンテンツの表示があります。基本的には、メインのHTTPリクエストのコンテキストに応じて、複数のページにまたがって、場合によっては異なる場所に表示する必要があるコンテンツです。
通常、従来のMVCフレームワークは、これらのタイプのコンテンツ構造に対する直接的な答えを提供しないため、人々は通常、レイアウトの複製と切り替え、カスタムヘルパーの使用、独自のウィジェット構造またはライブラリファイルの作成、または要求されたメインからの無関係なデータビューにプッシュスルーし、パーシャルでレンダリングするコントローラー。特定のコンテンツをレンダリングしたり、必要なデータをロードしたりする責任は、複数の領域に漏れて、使用される場所で複製されるため、これらはいずれも特に良いオプションではありません。
HMVC、または特にこれらの責任を処理するためにコントローラーにサブリクエストをディスパッチする機能は、明らかなソリューションです。あなたが何をしているのかを考えると、それはコントローラー構造に正確に適合します。コメントに関するデータをロードして、HTML形式で表示する必要があります。したがって、いくつかのパラメーターを使用してリクエストをコメントコントローラーに送信し、モデルと対話し、ビューを選択すると、ビューにコンテンツが表示されます。唯一の違いは、完全に独立した完全なコメントページの代わりに、ユーザーが閲覧しているブログ記事の下にコメントをインラインで表示することです（ただし、HMVCアプローチでは、実際に同じコントローラーと「kill oneにあるように」この点で、HMVCは、コードのモジュール性の向上、再利用性の向上、および懸念のより良い分離の維持に努める自然な副産物です。これがHMVCのセールスポイントです。
Sam de FreyssinetのTechPortalの記事 HMVCでのスケールアウトについて考えることは興味深いですが、HMVCフレームワークを使用する人々の90％以上が現実的で実用的なものになるとは限りません。それから一日の利益。
コハナでは、少なくとも、HMVCリクエストは「内部的に」処理されるHTTPリクエストです。ネットワーク経由で発行されるのではなく、フレームワーク自体によってルーティング、ディスパッチ、処理されます。 「HMVC」と「MVC」という名前の類似性は、実際には存在しない用語間の根本的なつながりを示唆しているという点で混乱を招きます。一方は他方のマイナーバリアントまたは修正ではなく、完全に異なるものです。 （HMVCは、クライアント側のHTTPリクエストを伴わないAjaxとも呼ばれます。）Kohanaが「HMVC」を重視し、サポートしていることは、フレームワークがHTTPベースのサービス指向アーキテクチャを強力にサポートしていることを意味します。
このアーキテクチャパターンの利点は、同じ「呼び出し規約」が内部要求と外部要求に使用されるため、必要に応じて「内部」サービス要求を「外部」要求に、またはその逆に変換するのは簡単なことです。
これは賢明なアーキテクチャパターンですが、独自の名前を付ける必要はないようです（Symfony2は同じ概念 " sub-requests "）であり、実際には名前は誤った名前のようです。特に要件はありません。または、要求が階層を形成する必要がある（すべての命令型プログラムの標準呼び出しグラフ以外）。たとえば、リクエストは簡単に再帰できます。
[2011年4月、2012年3月の更新：コメントへの回答で回答が展開されました。]
HMVCは、ディスパッチに対する「コンポーネントベース」のアプローチと密接に関連しています。基本的に、コントローラに委任する単一のディスパッチャを使用する代わりに、各コントローラはそれ自体でディスパッチャとして機能できます。これにより、コントローラーの階層が得られます。設計はより柔軟性があり、コードのカプセル化が向上しますが、より高い抽象性が犠牲になります。 Konstrukt はこのパターンを中心に設計されています。
この回答も参照してください： https://stackoverflow.com/questions/115629/simplest-php-routing-framework/120411#120411
HMVCは階層モデルビューコントローラーです。通常のMVCでは、すべてのGUIオブジェクトにMVCがありますが、HMVCとは異なり、親GUIオブジェクトと子GUIオブジェクトの間に関係はありません。 HMVCでは、各GUIオブジェクトはその子オブジェクトにアクセスでき、各子オブジェクトはその親オブジェクトにアクセスできます。
したがって、すべてのビューには親ビューがあり、それを介して親ビューにアクセスできます。すべてのコントローラーには、イベントを親コントローラーに渡すことができる親コントローラーがあります（イベントがスコープ内にない場合）。
詳細については、 こちら をクリックしてください
新しいリンクは このアドレス です