pjaxまたはクライアント側のMVC？

Question

私は新しいプロジェクトを始めなければなりません。フォームやスクリーンがたくさんあるWebアプリケーションでは、どの技術が最も適しているのかわかりません。アプリケーションは非常に少数のアニメーションと多くのフォームを備えたERPのようなアプリです。目標は最小限のリロードと待ち時間を減らすことで、通常のデスクトップアプリにできるだけ近づける必要があります（素晴らしいVB6アプリのように見える多くの作業:-)

クライアント側のMVC（バックボーン）。クライアントですべてのコードを実行するのはクールですが、これはサーバー（PHP + Fuel）から多くのコード（たとえばすべてのモデル定義）が繰り返されることを意味します。確かに一度、すべての情報タスクをページングやグリッドワークのような遅れなくロードしましたが、同期の問題もあります（他のユーザーはデータを変更でき、クライアントのデータを手動で無効にする必要があります）。

一方、私たちはpjaxを持っています。考え方はサーバー上でテンプレートを作成することです。pjaxリクエストのフレームや新しいリクエストの全ページを表示せずにページを返すロジックを実装するだけです。コードの重複、非常に単純なクライアント側。

私はストーリーfrom basecampとfrom twitterを読んでいて、どちらも意味が分かりました。

MVCよりもpjaxの方が好きですが、多分私は何か不足していると思います。クライアント側のMVCよりもpjaxやpjaxのメリットに比べてMVCのメリットはどれですか？

どうもありがとう

Answer 1

BACKBONE.JSは、それは非常に良いAPIを持って本当になど、ポストバックませんが、起こってajaxianものをたくさん持って、相互依存のカスケードドロップダウン決して重く、単一ページのWebアプリケーションに適していますイベントやコレクションのために。豊富なクライアントサイドのjavascriptを持っている場合は、それを整理するのに役立つ方法です。サーバー側のアーキテクチャがデフォルトではRESTfulであることが期待され、RESTfulでないAPIに使用するには多少の努力を払わなければならないという意味で、意見があります。

私が取り組んでいるプロジェクトは、サーバー側にasp.net MVCを持つERP Webアプリケーションです。私はBackbone（テンプレートシステムとしてハンドルバーを持っている）、そして.net mvcが本当によく一緒に動かないことを学んだ。バックボーンに行くなら、実際にフルホッグにする必要があります（コントローラメソッドがjsonを提供します、それだけです）。このアプリのページでは、「通常の」ウェブページにはいくつかのフォームがありますが、バックボーンは間違った選択です。

私はちょうど初めてpjaxを探そうとしていたので、基本的にはページ上部の短い説明を読んでいますが、Keep It Simple愚かな原則。