12

のCRUDを実行するアプリケーションがありCollectionますModels。DisplayView常に表示されるモデルごとにがあります。関連付けがクリックされたEditViewときにのみ表示されるもあります。DisplayView

DisplayViewとはEditView、さまざまな親ビューの内部に表示されます。現在、「イベントアグリゲーター」パターンを使用して、aがクリックされたEditViewときにレンダリングするようにアプリケーションに指示しています。DisplayViewここで説明するパターン：http：//lostechies.com/derickbailey/2011/07/19/references-routing-and-the-event-aggregator-coordinating-views-in-backbone-js/

私の1つDisplayViewがクリックされると、その親がEditViewsリッスンするイベントが発生します。このイベントを受信するEditViewと、イベントが発生したモデルに基づいて、適切なをレンダリングします。

これは私のアプリケーションのほとんどでうまく機能しますが、アプリケーション内EditViewの関連するものの絶対位置に基づいて位置を変更したい場合は特に面倒DisplayViewです。DisplayViewの位置を直接制御するのではなくEditView、「これらの座標に自分を再配置してください」イベントをトリガーします。このような直接通信は、アプリケーション全体にブロードキャストする必要があるもののようには感じられません。私の場合、それらを分離するのではなくEditView、それぞれのプロパティとして適切なものへの参照を持っているべきかどうか疑問に思い始めています。DisplayView

問題は、私が言ったように、それらが異なる親ビュー内にレンダリングされることです。DisplayViewsgetはでレンダリングされ、HeaderViewgetはでEditViewsレンダリングされますContentView。

他の人はこのような状況をどのように処理しますか？はEditViewいくつかの点でに属しますDisplayViewが、それは私のアプリケーションのDOMの構造とは一致しません。EditViewそれぞれとの間に直接リンクを作成すると仮定するとDisplayView、の表示/非表示をどのように処理しEditViewますか？DisplayViewコンテナへの参照も必要でしょうかContentView。これは、適切なEditViewパラメータを使用して明示的にレンダリングされますか？

4

3 に答える 3

15

可能な限り、（親/子ビューとは対照的に）並列ビューへの参照を保持し、相互に変更するビューは絶対に避けてください。これにより、すぐにスパゲッティに変わり、コードがはるかに壊れやすくなります。代わりに、次のパターンを使用すると、さまざまなビューを切り離したまま、作業を完了できます。

グローバル通知/イベント

これはあなたが言及したものです。それは機能しますが、あなたが言ったように、それは不必要にグローバルスコープでそれ自体をブロードキャストするのでエレガントではありません

バインディング/オブザーバーパターン

コントローラで名前を付けたオブジェクトを作成し、editViewPositionメソッドを公開して、表示ビューがeditViewPositionの値を変更できるようにします。次にEditView、はの変更をリッスンして監視し、editViewPositionそれに応じて自身を更新できます。このアプローチの強みは、後で5つの異なるEditViewsすべてがコントローラーの同じプロパティeditViewPositionを監視し、それに応じて更新できることです。そのために変更する必要はありませDisplayViewん。

デリゲートパターン

ビューを直接接続してメソッドを相互に呼び出す代わりに、表示ビューにdelegateプロパティを持たせることができます。このプロパティは、コントローラーによってeditビューとして設定できます。編集ビューを更新する必要がある場合は、デリゲートが存在するDisplayViewかどうかを確認し、事前定義された関数を実装します。存在する場合は、関数を呼び出します。このアプローチはオブザーバーパターンよりも結合されていますが、それでも高度な分離が可能です（たとえば、後で、編集ビューの代わりに完全に異なるビューを交換でき、プログラムは引き続き機能します）。このアプローチの弱点は次のとおりです。通常、デリゲートは1つだけですが、他のどのパターンよりも直接的です。

通知するオブジェクトのリストを手動で維持する

これは、ほとんどデリゲートパターンの拡張です。基本的EditViewに、表示ビューには同様のオブジェクトの配列があり、必要に応じて、表示ビューは配列を通過し、それらの各オブジェクトのメソッドを呼び出します。この配列は、コントローラーによって再び入力されます。

結論

個人的には、ユースケースにバインディングとオブザーバーのパターンを使用する可能性があります。一般に、並列である（直接の親/子関係がない）ビューは、相互に参照を保持するべきではなく、共有する共通のコントローラー/イベント/通知/その他の上部構造を介してのみ通信する必要があります。

于 2012-01-15T16:09:31.693 に答える
1

Tonyによって列挙されたオプションに加えて、とDisplayViewの最も近い共通の親ビューにクリックされたときにトリガーされるイベントを「バブリング」する別のオプションがDisplayViewありますEditView。イベントを使用して、表示ビューとそれが表すモデルの座標を渡します。次に、共通の親がでメソッドを直接呼び出して、メソッドEditViewを再配置し、適切なモデルをレンダリングします。したがって、並列ビュー間の明示的な参照やグローバル変数はありません。

複数のビューレイヤーでイベントをバブリングすると、バックボーンの組み込みメソッドtriggerとlistenToメソッドを使用すると面倒になりますが、Backbone.Courierプラグインを使用すると非常に簡単になります。

https://github.com/rotundasoftware/backbone.courier

于 2013-02-04T07:17:48.603 に答える
0

すでにアプリケーションを切り離している場合は、そのままにしてください。ビュー間に直接の依存関係を導入すると、アプリケーションの保守性が低下し、全体的に操作が煩雑になります。

イベントはここに行く方法です。

于 2012-01-13T14:45:45.213 に答える