BackBone.jsをASP.NETWebFormsアプリケーションに実装する必要がありますか？
バックグラウンド
私のグループの現在のWebアプリ開発パターンを改善しようとしています。現在のパターンは、ASP.NET WebForms上でリッチWebアプリを試しているときに思いついたものです（ASP.NET MVCを知っている人は誰もいませんでした）。これは現在のパターンです：
！
アプリケーションはWinFormsフレームワークを使用しています。
- ASPXページは基本的にHTMLであり、WebControlはほとんど使用していません。
JavaScript/jQueryを使用して、すべてのUIイベントとAJAX呼び出しを実行します。
単一のASPXページの場合、単一の.jsファイルがあります。
AJAX呼び出しはすべてPOSTです（RESTfulではありません）
AJAXは、一連のASMXファイルで定義したcontact WebMethodsを呼び出します。
- ビジネスオブジェクトごとに1つのASMXファイル。
なぜ変化するのか？
いくつかの理由で、パターンを少し修正したいと思います。
- JavaScriptファイルが少し扱いにくくなっていることに気づき始めています。
- ローカルデータとDOM更新の同期を保つために、さまざまな方法を使用しています。同期を保つためにコードの記述に時間がかかりすぎるようで、デバッグが難しくなる可能性があります。
私は読んでいます Backbone.jsアプリケーションの開発 そして私はコード編成と関心の分離の点でBackboneが提供しなければならないものの多くが好きです。しかし、RESTfulアプリの章にたどり着き、Backboneの使用に少しためらいを感じ始めました。
問題
問題は、WebMethodがRESTfulパターンに実際には適合しないことです。これは、BackboneがRESTfulパターンを利用したい方法であると思われます。
今のところ、まとまりのないクライアント側コードの問題にのみ対処したいと思います。 WebMethodsの大幅な書き換えは避けたいと思います。
私の質問
データアクセスWebMethodsに大きな影響を与えずに、Backbone（または同様のライブラリ）を使用してクライアントコードをクリーンアップすることは可能ですか？それとも、このようにバックボーンを使おうとすると、意図された用途のろくでなしになるでしょうか？
コード編成の分野でパターンを改善し、DOMとデータ同期コードの記述に費やす時間を減らすための提案はありますか？
これは、コードをどのように設計および記述したかに大きく依存しますが、Backbone.jsを使用できるようにアプリケーションを改造することは可能です（いいえ、必ずしも野郎だとは思いません）。
あなたがする必要があるのはあなたの呼び出しをどこかであなたのウェブサービスが理解できる何かに翻訳することです。これには2つの方法が考えられます。
REST呼び出し）を送受信するサーバー側APIラッパーを作成します。基本的に、バックボーンアプリケーションがインターフェイスする「API」/「ルーター」クラスを作成します。このAPIは、REST呼び出しをWebサービスが理解するものに変換します。次に、Webサービスからの情報を、Backboneアプリケーションが理解するRESTful応答に変換します。これは、 WebMethodsはサーバー上の他の関数（IE-"var foo = bar.GetData（）"など）から直接呼び出すことができます。
Backboneの同期メソッドを独自のものでオーバーライドします。組み込みのSync関数を独自のものでオーバーライドすることもできます。これを行うと、送受信するデータのタイプを理解できる同期関数セットを構築できます。これは、アプリケーションからのRESTコマンド（get、set、update、delete））を、Webサービスに準拠するコマンドに変換します。
個人的には、可能であればサーバー側のコードにラッパーを配置することをお勧めします。これにより、クライアント側のコードを再度作成しなくても、将来更新できるようになります。ただし、オプション2のルートに進む必要がある場合は、WebサービスがRESTful APIであるかのように、Backboneアプリケーションの残りの部分を記述してみてください。こうすれば、Sync関数をVanilla Backbone.Syncに簡単に置き換えることができます。サーバーを変換しました。