Demeterの法則に違反することなく、Marionetteモジュール間の通信を処理するのに最適

Question

私は現在、ES6とMarionette v3を使用してMarionetteコードベースを書き直しています。

私はサブモジュール（ProductShowRoute、CartManagerなど）をいくつか作成しましたが、これはすべて私のメインのAppから始まりました。

皆さんがモジュール間のコミュニケーションをどのように管理しているのだろうかと思いました。以前のMarionetteアプリでは、コミュニケーションがあまりにも忙しく、Backbone.Wreqrを使用して送信されすぎていました。

ユーザーがカートに商品を追加すると、ProductsModuleはCartModuleにこれを知らせる必要があります。あまりにも多くのスパゲッティコードを書かずにこのコミュニケーションをどうやって整理していますか？ Backbone.Radio/Backbone.Wreqrはすばらしいツールですが、間違って使用された場合（またはモジュール間で多すぎることが起こった場合）、どのイベントがどこで終了するのかを知ることは困難です。

また、どのように経路を変更しているのでしょうか。私はApp.navigate(‘route’, { trigger: true })の使用を警告したDerick Baileyのブログ記事を読むが、Marionette Wiresでは数回起こっているのを見た。 trigger: trueは本当に使いにくいですか？そして、私たちにはどのような選択肢がありますか？以前はBackbone.Wreqrを使用していましたが、これは各モジュールのRouterを呼び出してルートを変更しますが、これは多くの通信が前後しているようです。

ありがとうございます！

subAppsとの間の通信のためのバーノン

Answer 1

、私は、アプリのどこかのイベントレジストリを有し、それらの作用を示し、そのチャネル上のメソッドをトリガする各subAppを好みます。私はこれを行うのが好きなので、イベントが発生したときの行動のリストを明確に見ることができます。また、私の意見では、それはイベントがApp.navigate('route', {trigger: true});に関しては

// Fire an event. 
ProductsModuleChannel.trigger('product:added', productModel); 

// Event Registry 
App.listenTo(ProductModuleChannel, 'product:added', function (productModel) { 
    CartManager.addProduct(productModel) 
}) 

を解雇された後、私は「ルート駆動」であるとするアプリケーションを好きではない何が起こるかProductsModulesの懸念もはずの。ルートはアプリケーションのエントリポイントでなければなりませんが、それはそれです。私は、次の

... 
showSomePage: function() { 
    // Render some views and do other things 

    // Update the route 
    App.navigate('myRoute'); // Note no 'trigger: true' 
} 

希望のような何かをする傾向があり、この

を支援