マッピング プラグインを使用して、サーバー側のドメイン オブジェクトを厳密に反映する深いオブジェクト グラフを操作する、かなり複雑な Knockout.js アプリの途中です。私自身の少しぎこちないコンテキストでかなりうまく機能するものに行くにつれて、パターンを改良してきましたが、MVVM Javascriptにアプローチする全体的な方法が良いか悪いかを知りたいです。
基本的に、私のページ パターンは、コントローラーのように機能するモジュール関数を明らかにすることです。ビュー モデルの階層を所有し、変更を検出し、サーバーへの変更を Ajax し、マッピング プラグインを使用してビュー モデル グラフを更新します。 JSON として応答で返される可能性のあるフローオンの変更。私のドメインは、サーバーで検証されたときにグラフの一部の小さな変更がグラフの離れた部分の変更/削除につながる可能性があるため、このようにしました。これが発生した場合、変更を再マップしたり、メッセージダイアログをユーザーに表示したりするための共通点が必要です。
私のビュー モデルはすべてインスタンス化可能な関数であり、それらが使用されているページやサーバーについて何も認識しないように設計しました (つまり、独自の Ajax を実行しません)。各ビュー モデルのコンストラクターは、マッピング オプションを介してその子を作成し、各レベルにはその親への参照が渡されます。私は、ほとんどのビュー モデルが使用する一般的なダーティ フラグを実装しました。変更が発生すると、モジュールがサブスクライブしている上部にある監視可能な「ダーティ ビュー モデル」へのチェーンを自分自身への参照に渡します。これは少し奇妙に聞こえるかもしれませんが、各レベルのアイテムが常に追加および削除されているため、初期化時にプロパティを静的にサブスクライブできないため、これが最善のアプローチのように思えました。そして、私はしません
純粋な効率の観点からは、これは最善ではありません。最も簡単な方法は、各ビュー モデルが必要なときにモジュール内の関数を直接呼び出すことですが、そのタイプの結合は間違っている必要があります。または、モジュール (または関連する関数) への参照を各ビュー モデル コンストラクターに渡し、ビュー モデルがそれを呼び出します。これは、Javascript の依存関係の挿入に少し似ています。しかし、それは抽象的すぎるようです。これはそのままでは十分に複雑です。
これらすべての上に座るために、バックボーンなどのより高いレベルのフレームワークを検討する必要がありますか? モジュール参照の注入は本当に抽象的すぎますか? それとも、このような構造化の方法は、基本的にそのままで意味があるのでしょうか? 同様に困難なシナリオに取り組んだ経験のある方から、どのようにパターンを進めて洗練させたのかを聞きたいと思っています.
編集: さまざまな理由から、このアプリは "save as you go" モードで動作することを明確にする必要がありました。これにより、特定のレベルでの変更により、その 1 つのビュー モデル (その子を除く) の個別の Ajax ポストが即座に作成されます。サーバーに送信されます (他のほとんどすべてへの変更を表す結果が返される場合があります)。純粋なクライアント側のアクションとは対照的に、一定の Ajaxing が必要なこの面倒な必要性にもかかわらず、Knockout.js は私のアプリを Olde の MVC アプリよりもはるかにエレガントで、保守しやすく、スケーラブルにしています。