私が使用しているPHPフレームワーク(Kohana)は、最近HMVCアーキテクチャを実装しました。リクエストが相互に行われるレイヤードMVCであることを読みました。これはajaxに少し似ていますが、純粋にサーバー側です。いくつかの実験に少し適用しましたが、どのプロジェクトにも適用できません(必要性が見つからないため)。これまでにプロジェクトでHMVCを使用したことがありますか?どのように役立ちましたか?
3 に答える
これはajaxに少し似ていますが、純粋にサーバー側です。
これは良い例えです。
HMVCは、ページにウィジェットを追加するのに最適です。これは、いくつかのページで再利用するコンテンツのモジュラービットです。たとえば、ショッピングカートウィジェット。同じことをさまざまな方法で行うことができます。
- 図書館。私たちは、再利用可能なコードをコントローラーからライブラリーに移動することに慣れています。次に、コントローラーから、そのライブラリーへの呼び出しの結果をビュー変数にロードできます。
- ビュー。メインビュー内からビュー(部分的)をロードできます。そのビューパーシャルは、モデルからコンテンツを取り込むことができます。ビューからモデルを呼び出すことは必ずしも人気があるとは限りませんが、必ずしも間違っているわけではありません。
ただし、KohanaHMVCにはいくつかの利点があります。
- 一貫性-HMVCリクエストは外部httpリクエストと同じように扱われます。
- 電源-HMVCリクエストには、ルートを含むhttpリクエストと同じKohanaリソースがあります。
- プラグ可能性-ビューから呼び出された場合、HMVC要求には、コントローラー(ライブラリーの結果をビューに割り当てる)とビューのプレースホルダーの間にカップリングがありません。2つではなく1つのファイルに触れるだけです。
私は、HMVCの事例と、Kiallによってリンクされたhttp要求によるスケーラビリティを評価し始めています。同じことがCURLでも実行できます。ただし、最初からCURLよりもKohanaHMVCを使用して設計する方が自然かもしれません。
そうですね-コハナの開発者の1人であるSamdeFreyssinet(別名samsoir)は、最近この質問を扱った記事を公開しました。
http://techportal.inviqa.com/2010/02/22/scaling-web-applications-with-hmvc/
HMVCの唯一の用途ではありませんが、最も人気のある用途の1つです。この記事は主にスケーラビリティ(1秒あたりのリクエスト数など)に関係していますが、コードのスケーラビリティ(コードの保守がどれほど簡単/難しいかなど)も同じアイデアで「解決」できます。
お役に立てれば :)
(補足-彼のコードサンプルは、サムのコハナへの個人的な変更に基づいています-記事の最後にあるメモを参照してください)
単純なプロジェクトでは、HMVCアーキテクチャパターンの実際の使用法さえ見つけられないかもしれません。そして、あなたも試してはいけません。これが理由です:
HMVCアーキテクチャを作成する上での重要な点は、MVCを少し乾燥させることでした。HMVCの主な利点の1つは、コードの再利用です。これにより、アプリケーション全体で繰り返されるフラグメントを作成できます(同じ場所で繰り返される場合もあれば、そうでない場合もあります)。
小さなテストアプリケーションとして作成している場合、繰り返し可能なフラグメントはありません。したがって、HMVCの可能性を最大限に活用する必要はありません。最終的には、標準のMVCであるHMVCのレベルが1つになります。