1

私は最近breezejsを試していて、個人的にも職場でも多くのプロジェクトに使用することを検討していました。現在、シングル ページ アプリが大流行していることは承知していますが、新しいルーティング フレームワークを導入したくなく、.NET MVC の既定のルーティング エンジンだけを使用することに慣れているとしましょう。POST/Redirect が発生するたびに、Metadata およびその他のエンティティに対する Breeze のエンティティ マネージャのクライアント側のキャッシュ機能が失われます。

問題の 1 つは、リクエストごとに大量のメタデータ (.5 mb) が送信されることです。リダイレクトの前にクライアント側に追加のリクエストがある場合、そのメタデータはキャッシュされ、すべて問題ありません。エンティティマネージャーにもキャッシュする静的リストに加えて、各ビューのメタデータをダウンロードする必要を回避しようとしています。より小さなオブジェクト グラフを作成することでメタデータを最適化できることはわかっていますが、それには焦点を合わせません。

私が思いついたのは、メタデータを localStorage に保存し、ページの読み込み時に取得することです。

function exportMetadata() {
   var metadata = emanager.metadataStore.exportMetadata();
   window.localStorage.setItem('somename', metadata);
}
function importMetadata() {
   var metadata = window.localStorage.getItem('somename');
   var mstore = new breeze.MetadataStore();
   mstore.importMetadata(metadataFromStorage);
   manager.metadataStore = mstore;
}

これは機能しますが (異なる構文の静的リストでも機能します)、ハックに感じられ、ライブラリの使用方法に反するようです。BreezeJS が SPA アーキテクチャに結合されて、記述されているすべての機能を利用していると思わずにはいられません。多分私はそれについて間違った方法で考えていますか？SPA 外で BreezeJS を使用する方法の提案や例はありますか?

4

1 に答える 1

2

Breeze は、ページ更新の間に長いユーザー セッションがあると想定されるシングル ページ アプリ (SPA) を対象としています。クライアント側のルーティング フレームワーク (Durandal や Angular など) が必要ない理由がわかりません。しかし、ときどきページを切り替えたいと思うことは確かにあります。

これは、アプリケーションが実際には小規模なモジュール式アプリの連合であり、それぞれが独立して開発および保守されており、ユーザーがあるモジュールから別のモジュールに「橋」を渡る場合にも推奨される方法です。

あなたのソリューションはまさに私がしたことです:ブラウザのローカルストレージからメタデータを隠して復元します。あなたが言うように、それを単一のシリアル化されたキャッシュ内のメタデータの隠し/復元と（ほとんどの場合）静的参照リストエンティティと組み合わせることができます。

このプラクティスを採用することは、IMO ではまったくハックではありません。私たちは、Breeze がこのように機能することを意図していました。実際、これは「通常の」SPA の起動とロードの時間を短縮する優れた方法です。

これが「ハッキー」だと思う理由を知りたいです。Breeze がこの練習なしであなたのために何ができるかについてのあなたの考えにも興味があります. 理想の世界とは？

于 2013-10-31T23:03:12.653 に答える