1

以前のビルドでは setProperties を使用し、trackingImplementation を省略しましたが、手動でノックアウトを使用して高速化することにしました (エンティティがたくさんあります)。

現在、この構文に変更されています。「ko」行をコメントアウトしても、オブザーバブルが作成されますが、これを防ぐ方法はありますか?

core.config.initializeAdapterInstances({
//        modelLibrary: "ko",
          dataService: "webApi"
});
4

2 に答える 2

2

約 5000 ～ 10000 個のエンティティをキャッシュにロードしています。これらは「ゲスト」であり、夕方にゲスト リストから除外されます。接続が失われるとアプリが機能しなくなるため、オフラインで保存する必要があります。私は追加のヒットを持つモバイル デバイスでも実行しています。KO を使用すると、サーバーから渡されたすべてのエンティティが監視可能なプロパティのリストになります。これは明らかにやり過ぎであり、iPhone でサファリがクラッシュします。代わりに、ユーザーが Breezejs ローカル クエリを使用して 10,000 のエンティティから検索を実行するのを待ち、検索結果の各ゲストに対して、監視可能なゲストをインスタンス化します。これにより、バインドにノックアウトを使用できるようになり、残りのエンティティはそのままにしておきます。これはうまく機能し、iOS デバイスでもうまく機能します。「エンティティの拡張」を今読んでいるだけです

ありがとう

于 2012-11-30T01:17:13.690 に答える
0

あなたのコメントで、あなたが試したことがわかります...modelLibrary: backingStore...。これを提案するつもりでした。しかし、手動の KO プロパティが backingStore プロパティをバイパスし、車輪が外れるのではないかと心配しました。backingStore プロパティを読み書きする KO 計算を追加すれば (まだ試していませんが) うまくいくと思いますが、競合しない名前が必要ですよね?

少しの間、根本原因に戻りましょう。ko モデル ライブラリの何が遅すぎて、何がより速いのですか? KO プロパティの定義がどのようにパフォーマンスの問題になるか想像できません。速度の違いをどのように測定しましたか？速度の違いは何ですか？

また、「エンティティの拡張MetadataStore」で説明されているように、独自のエンティティ タイプ コンストラクタで KO プロパティを定義し、そのコンストラクタを に登録しようとしましたか?

于 2012-11-29T16:24:06.943 に答える