WiredPrairie が提案したように、バックボーン アプローチ (および、私が主張する「スマート プログラマー」アプローチ) は、物事を別々のコンポーネントに分割することです。
すべてのプログラマーは、人間として、一度に非常に多くのコードに頭を悩ませることしかできません。コードで大規模なクラスを作成しようとすると、基本的に、関連するすべての部分を一度に「メモリ内」に保持できないことが保証されます。さらに、ほぼ全員が、テストはコードの保守性の重要な部分であり、大きなクラスはテストを阻害することに同意します。
最終的には、いくつかの巨大なクラスは必要ありません。アプリケーションを作成するために連携する多数の小さなクラスが必要です。このアプローチでは、扱いやすいサイズになるため、作業しているクラスを簡単に理解できます。また、そのクラスとやり取りするすべてのクラスの一般的な動作も、一度に頭の中に入れておくことができます。さらに、各クラスには 1 つの目的と、テスト対象の (適度なサイズの) 操作セットが 1 つしかないため、単体テストを簡単に作成できます。
バックボーンはこれを非常にうまくサポートします。確かなことは言えませんが、Jeremy Ashkenas はView、サイト全体に 1 つだけを持っている人がいるとは思っていなかったと確信しています。それどころか、彼はサイト (少なくとも通常のサイト) が多くViewsのサイトを組み合わせてサイトを作成することを期待していたに違いありません。同様に、すべてを 1 つの巨人でやろうとすることは、ModelBackbone の使用目的に反することになります。
Backbone を使用して、小さなコンポーネント間の「点をつなぐ」方法はたくさんあります。たとえば、本当にすべてのデータを一度に保存する必要がある場合でも、1 つだけが必要というわけではありませんModel。同期を処理する 1 つの「マスター」を作成し、それにor otherModelである一連のプロパティまたは属性を与えることができます。次に、メソッドをオーバーライドしてそれらの/を設定し、そのマスターのメソッドをオーバーライドして、そのサブモジュールとサブコレクションの toJSON 結果を使用できます。CollectionsModelsinitializeModelsCollectionstoJSONModel
または、子クラスのメソッド (または や などの個々の CRUD メソッド) を上書きして、/ /何かしようとすると、sync実際にマスターオブジェクトの保存がトリガーされるようにすることもできます。または、オーバーライドして、発生するすべての操作を監視し、サブオブジェクトからの操作を防ぐことができます。または、できます...savefetchfetchsaveBackbone.sync
重要なのは、ほとんどすべてのプログラマーが、すべてを 1 か所で一度に実行しようとするよりも、多くの小さなパーツを接続することをお勧めするということです。Backbone は非常に強力で柔軟なライブラリであるため、まさにそれを行う方法がたくさんあります。