私はBackbone Fundamentalsを読んでいて、新しいプロジェクトでメディエーターとファサード パターンを使用することを計画していましたが、読んでいて、なぜアプリのメイン ルーター オブジェクト、または拡張するオブジェクトを使用できないのか疑問に思っていました。本で概説されているように、サブスクライブおよびパブリッシュ メソッドを実装するのではなく、メディエーターとして Backbone.Events を使用します。
Backbone 0.9.9 のドキュメントで、Backbone オブジェクト (現在は Backbone.Events から拡張されている) をグローバル イベント バスとして使用することが明示的に言及されているため、これについてさらに興味があります。これが良い選択肢であるかどうか、そしてそうでない場合はその理由を誰かが明確にすることができますか?
Backboneルート オブジェクトをメディエーターとして使用しても問題はありません。アプリケーションのメイン ルーターをイベント バスとして使用することは必ずしも良い考えではありません。これは、ルーター インスタンスがアプリケーションのすべての部分からグローバルにアクセスできる必要があるためです。バックボーン ルート オブジェクトを使用すると、この落とし穴を大幅に回避できます。これは、既にグローバルなシングルトン インスタンスであるためです。
メディエーターとして使用しない理由を実際に探したい場合Backboneは、そうするとすべてのパブリッシャーとサブスクライバーがBackboneに結合され、コンシューマー コードの移植性が低下すると主張できます。さらに、公開するインターフェイスを制御できなくなります。BackboneAMD/モジュール パターンでは、これは、ルート オブジェクトにアクセスするビジネスを持たないモジュールにバックボーンをインポートする必要があることを意味します。
あなたのアプリケーションはそのままバックボーンに完全に依存している可能性が高いため、これは問題ではないと思います。しかし、偏執的であると感じている場合はBackbone.Events、グローバル オブジェクトを公開せずに実装を使用できます。
//mediator.js
define(['backbone', 'underscore'], function(Backbone, _) {
return _.extend({}, Backbone.Events);
});
この場合、消費者は実装ではなくインターフェイスに依存するだけであり、on、offおよびtriggerメソッドを自分で実装するだけで、メディエーター メディエーターの実装の詳細を変更できます。