Kohanaのドキュメントを読んで、3.0バージョンの主な違いは、バージョン2.xのようにMVCではなくHMVCパターンに従うことです。コハナのドキュメントのこのページとウィキペディアのページは、私に明確なアイデアを与えませんでした。
だから質問:HMVCパターンとは何ですか?それはMVCとどう違うのですか?
Kohanaのドキュメントを読んで、3.0バージョンの主な違いは、バージョン2.xのようにMVCではなくHMVCパターンに従うことです。コハナのドキュメントのこのページとウィキペディアのページは、私に明確なアイデアを与えませんでした。
だから質問: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/
現在、Alloyと呼ばれる独自のPHP 5.3 HMVCフレームワークを開発中です。私はHMVCに多額の投資と販売を行っているので、別の見方をすることができ、HMVCを使用する理由とHMVCがもたらすメリットをよりよく説明できると思いました。
HMVCアーキテクチャを使用する最大の実用的な利点は、コンテンツ構造の「ウィジェット化」です。たとえば、コメント、評価、TwitterまたはブログのRSSフィードの表示、eコマースWebサイトのショッピングカートコンテンツの表示などです。これは基本的に、メインのHTTPリクエストのコンテキストに応じて、複数のページにまたがって異なる場所に表示する必要があるコンテンツの一部です。
従来のMVCフレームワークは通常、これらのタイプのコンテンツ構造に直接的な回答を提供しないため、一般的に人々はレイアウトの複製と切り替え、カスタムヘルパーの使用、独自のウィジェット構造またはライブラリファイルの作成、またはメインリクエストからの関連のないデータの取り込みを行います。ビューにプッシュスルーして部分的にレンダリングするコントローラー。特定のコンテンツをレンダリングしたり、必要なデータをロードしたりすることで、複数の領域にリークし、使用されている場所で複製されるため、これらは特に優れたオプションではありません。
HMVC、または特にこれらの責任を処理するためにコントローラーにサブリクエストをディスパッチする機能は、明白なソリューションです。あなたが何をしているのかを考えると、それはコントローラーの構造に正確に適合します。コメントに関するデータをロードし、HTML形式で表示する必要があります。したがって、いくつかのパラメーターを使用してコメントコントローラーにリクエストを送信し、モデルとやり取りしてビューを選択すると、ビューにコンテンツが表示されます。唯一の違いは、コメントをインラインで表示することです。完全に別の完全なコメントページではなく、ユーザーが表示しているブログ記事の下に表示します(ただし、HMVCアプローチでは、実際には同じコントローラーで内部と外部の両方のリクエストに対応でき、「killことわざにあるように、1つの石を持つ2羽の鳥」)。この点について、HMVCは、コードのモジュール化、再利用性の向上、および関心事の分離の向上を目指す努力の自然な副産物です。これがHMVCのセールスポイントです。
したがって、HMVCでのスケールアウトに関するSam de FreyssinetのTechPortalの記事は興味深いものですが、HMVCフレームワークを使用する人々の90%以上が、実際的で実用的な日常的なメリットを享受できる場所ではありません。
HMVCは、ディスパッチに対する「コンポーネントベース」のアプローチと密接に関連しています。基本的に、コントローラーに委任する単一のディスパッチャーを持つ代わりに、各コントローラーはそれ自体がディスパッチャーとして機能できます。これにより、コントローラーの階層が得られます。設計はより柔軟で、コードのカプセル化が向上しますが、抽象度が高くなります。Konstruktはこのパターンを中心に設計されています。
この回答もご覧ください:https : //stackoverflow.com/questions/115629/simplest-php-routing-framework/120411#120411
コハナでは、少なくともHMVCリクエストは「内部」で処理されるHTTPリクエストです。ネットワーク経由で発行されるのではなく、フレームワーク自体によってルーティング、ディスパッチ、処理されます。「HMVC」と「MVC」の名前の類似性は、実際には存在しない用語間の根本的なつながりを示唆しているという点で混乱しています。一方はマイナーバリアントまたはもう一方の変更ではなく、完全に異なるものです。(HMVCは、クライアント側のHTTPリクエストなしのAjaxとも呼ばれます。)コハナが強調し、「HMVC」をサポートすることは、フレームワークがHTTPベースのサービス指向アーキテクチャーを強力にサポートすることを意味します。
このアーキテクチャパターンの利点は、内部要求と外部要求に同じ「呼び出し規約」が使用されるため、必要に応じて「内部」サービス要求を「外部」要求に、またはその逆に変換するのが簡単であることです。
これは賢明なアーキテクチャパターンですが、独自の名前を付けることは不要に思われ(Symfony2は同じ概念「サブリクエスト」を説明します)、実際、名前は誤った名前のようです:特定の要件はなく、リクエストがフォームを形成する必要はありません。階層(すべての命令型プログラムの標準呼び出しグラフ以外)。たとえば、リクエストは簡単に再帰的になる可能性があります。
[ 2011年4月更新、2012年3月:コメントに応じて回答を拡大]
HMVCは階層モデルビューコントローラーです。通常のMVCでは、すべてのGUIオブジェクトにMVCがありますが、HMVCとは異なり、親GUIオブジェクトと子GUIオブジェクトの間に関係はありません。HMVCでは、各GUIオブジェクトはその子オブジェクトにアクセスでき、各子オブジェクトはその親オブジェクトにアクセスできます。
したがって、すべてのビューに親ビューがあり、それを介して親ビューにアクセスできます。すべてのコントローラーには、イベントを親コントローラーに渡すことができる親コントローラーがあります(イベントがスコープ内にない場合)。
詳細説明はこちらをクリックしてください
新しいリンクはこのアドレスです