シーンは次のとおりです:
このような操作は同時に多くのモデルに依存する必要があるため、これらのコードは特定のモデルには記述されません。
たとえば、ViewController で書かれた Backbone かもしれません...しかし、これはコードの再利用には良くなく、View がめちゃくちゃになってしまいます。
私の現在の解決策は、単一のファイルを使用してほとんどのモデル操作を収集することですが、問題は、このファイルのサイズが増大し続けて乱雑になることです。
では、このような問題はどのように解決すべきでしょうか?
さらに詳しい質問は、コードのこの部分をどのように整理するかということです。
たとえば、React の Flux ソリューションを使用して、プロセスをできるだけ明確にしようとしましたが、コードのこの部分をどこに配置すればよいかわかりませんでした。
Flux はユーザー操作をアクションに変換し、Store は Dispatcher を通じてこれらのアクションを監視します
1 つのアクションが複数のストアに対応する場合...問題が発生します:
ストアにそれぞれ対応する複数のアクションを使用する必要がありますか、それとも 1 つのアクションを複数のストアで監視する必要がありますか?
曾经蜡笔没有小新2017-05-16 17:08:22
ユーザーがボタンをクリックすることは、ユーザーが URL を通じてアクセスすることと本質的に同じです。これは「入力」であるため、問題と処理メカニズムは同じです。ビュー層のコードで「入力」を監視し、一部のビューを処理します。レイヤー (ボタン コンポーネントなど) の切り替え、URL 修正) 内部状態の変化、純粋でより高い抽象レベル (ビュー コンポーネントや URL の詳細に関係しない) データ/メッセージを生成/抽出し、ある種のイベント メカニズムを使用してブロードキャストします。あなたとは何の関係もありません。コントローラー層がある場合は、コードのこの部分でこれらのイベントをリッスンし、対応するモデル オブジェクトのメソッドを呼び出します (これにより、モデル オブジェクト自体間の依存関係と呼び出しがカプセル化される可能性があります)。ここでの 1 対多の複雑さは外部に公開されません)、また、特定のモデル オブジェクトの状態変化を監視し、対応するビュー オブジェクトのメソッドを呼び出します (または仮想 DOM を再レンダリングします)。すべては拘束されています。
たとえば、私は通常、NervJS (モデル) + DermJS (ビュー) + URLKit (ルート) の組み合わせを使用します。また、NervJS オブジェクトと DermJS オブジェクトには独自のイベント メソッドがあり、view/ を実行するときに統合バスを渡すこともできます。モデルオブジェクトが初期化されます。
UI コンポーネントを作成するときは、当然、特定のモデルに依存したくないので、one-to などのバインディングを使用します。 -多くは別の場所 (具体的にはビジネス ロジック コード) で完成します。 ビュー オブジェクトとモデル オブジェクトは、お互いにどれをいくつ持っているかを知る必要はありません。そのため、「複数のアクションをそれぞれストアに対応させる」ことは不可能です。 」。
「単一のファイル」と「継続的に増加するカオス」の問題については、ルーティング ファイルの設定と同じです。関連する経験を参照してください。
曾经蜡笔没有小新2017-05-16 17:08:22
流動的な状況において、複数のストアに対応するために 1 つのアクションが必要な場合は、実は簡単に解決できます。
ストアにコールバックを登録するときは、このアクションに応答するだけでよく、waitFor を通じて対応する順序を変更することもできます。
コードの混乱が心配な場合は、別の constants ファイルを作成して、トリガーされるイベントの名前を定義できます。
例:
ボタンをクリックしてトリガーsend事件，会更新两个Store分别是StoreA和StoreB。可以写一个constants.js、最初にイベント名を定義します:
定数:
リーリー次に、2 つのコールバックを登録します Store:
ストアA:
リーリーストアB:
リーリークリックイベントがトリガーされると、コールバックがAction中触发Disp的这个事件，就会顺序执行在StoreA和StoreBに登録されます:)
曾经蜡笔没有小新2017-05-16 17:08:22
まだ見ていない場合、または見たことがあるのに忘れてしまった場合、これは読む価値のある記事です:
大規模な JavaScript アプリケーション アーキテクチャのパターン
簡単に言うと、ビューとモデルが相互に依存する必要がないように（1:1 依存関係であっても 1:N 依存関係であっても）、「従来型」のものが必要です。
シンプルなイベントとオブザーバーのパターンを使用することもできます。ビジネス ロジックが複雑な場合は、メディエーターを使用してモジュール間の通信と同期を完了します。
追記: 理想的な状況は、各モジュールが自分自身 (どのイベントがトリガーされるか、どのイベントがリッスンされるか) のみを認識し、他のこと、ましてや相手のインスタンスやメディエーターのインスタンスについては何も気にしないことです。