HMVCとAJAXの周りにアプリケーションを設計する[Kohana 3.2]

Question

私は現在、いくつかの異なるページを持つアプリケーションを設計しており、各ページにはAJAXを通じて更新されるコンポーネントがあります。レイアウトは、「ホーム」、「ディスカバー」、「接続」が別々のページで、ページ内で相互作用する（フォロワーやフォローをクリックするなど）、AJAXを使用する新しいTwitterデザインと似ています。

デザインにはAJAXで個別に更新できるいくつかのコンポーネント（Twitterの文脈ではつぶやき、フォロワー、次のようなもの）がある初期ページの読み込みが必要なので、デフォルトページを提供するコントローラ、およびフルページを提供するのではなく、データベースのクエリとJSONオブジェクトの返却を厳密に処理するアクションを持つ他のコントローラです。このようにして、最初のページのロード時に、各コンポーネントのデータを収集するためにいくつかのHMVC要求を行うことができ、各コンポーネントを個別に更新するためにAJAX呼び出しを行うこともできます。

私の考えは、サービングページを処理するController_Defaultを持つことです。 Twitterでの文脈では、Controller_Defaultは含まれています：

action_home() 
action_connect() 
action_discover() 

を、私は、他の完全なページを提供して対処していないコントローラではなく、ページの要素を持っているでしょう。例えば、Twitterのコンテキストでは、Controller_Tweetは、特定のユーザのつぶやきを含むJSONオブジェクトを返す、

action_get() 

を持つことがあります。 Action_home（）は、ページのいくつかの異なるコンポーネントのデータを取得するために、いくつかのHMVC要求を行うことができます。（つまり、「ツイート/取得」、「フォロワー/取得」、「フォロー/取得」。しかし、このページでは、コンテンツを更新するために、関数特有のコントローラ（つまり、 'tweet/get'）にAJAX呼び出しを行うことができます。

私の質問：これは良いデザインですか？ページ構成要素が他の機能固有のコントローラを介して（JSON形式で）提供されている状態で、デフォルトのコントローラを介してページを提供するのは理にかなっていますか？

質問に関する混乱がある場合は、お気軽にお問い合わせください。

Answer 1

HMVCパターンの強みの1つは、このタイプのレイヤードアプリケーションを使用しても、後で変更するのが難しいワークフローに拘束されないということです。

上記の内容から、これはクライアントにコンテンツを提供する方法としては完全に受け入れられるでしょう。デフォルトのコントローラはサブリクエストをラップし、同じ目標を達成するためにクライアントからの複数のAJAXコールを回避します。私が作るかもしれない

つの提案：

1. あなたのTwitterのバックエンド要求がアプリケーションDRY'erと保守が容易に行うために、ライブラリに抽象化され、管理されていることを確認してください。
2. デフォルトのコントローラが各要求に対して絶対に必要な呼び出しのみを行っているかどうかを検討します。キャッシングを使用して、すべてのリクエストで頻繁に変更されないデータを取得しないようにします（フォロワーは30秒ごとに更新するなど）。これはもちろん、アプリケーションの要件に完全に依存しますが、負荷が大きくなると、Twitter APIのリクエスト制限にすぐに到達することができます。

最終的な観察：サーバーの負荷が高く、Twitter APIリクエストが返されるまでに時間がかかる場合は、別のサーバーのプロビジョニングとアプリケーションのコピーのインストールを検討してください。次に、デフォルトゲートウェイアプリケーションからサブアプリケーションを2番目のアプリケーションサーバーに「指す」ことができます。これにより、2つのサーバーが高速リンクで接続されている場合の応答時間を改善できます。