Ext JS商店和複雜對象

Question

我記得閱讀開發人員應該將商店中的記錄視爲數據庫中的行，其中每列都是簡單的數據類型。我們將複雜的JS對象存儲在Ext JS商店中，沒有任何明顯的後果。

有沒有人知道存儲JS對象在一個Ext JS商店的陷阱？

Answer 1

現代網絡瀏覽器已經非常善於管理這種內存使用和處理速度。在內部，我們已經實現了extjs 4現在內置的記錄關聯類型，並且具有存儲約250k個複雜嵌套記錄的場景，沒有任何實際問題。我相信，對性能的微不足道的影響將會持續很長時間，因爲它本身也很好地清理自己的內存使用情況。我們將我們的Web服務器的ORM模型映射爲extjs記錄定義，並以與我們打擊更傳統數據庫相同的方式定期查詢這些嵌套商店。您必須小心處理它，例如，試圖一次呈現250k條記錄的網格將無法很好地工作。但這幾乎完全是dom渲染的影響，而不是記錄/存儲數據的迭代或存儲。當用最近的extjs 4測試版進行測試時，所有這些似乎更加真實。

Answer 2

看看Ext JS源代碼，它似乎是一個Store是一個圍繞Object的包裝，它提供了排序/過濾和事件功能。這是一個簡單的鍵/值對。

對象的複雜性不應該引起任何問題。

現在將Store視爲除鍵/值對集合外的任何東西都會導致問題。認爲它像一張桌子會導致問題。這種誤解導致代碼設計不佳。

A Store應該作爲一個袋子的關鍵/價值數據與輔助方法來組織該袋子。

Answer 3

我想如果你的JS對象非常大，可能會有性能影響，如果你最終做了很多這些JS對象的序列化/反序列化，可能需要一些時間。如果你正在處理網格，你可以通過使用分頁來緩解這些問題。

商店不一定嚴格用於網格行。它們用於許多Ext對象，如組合框（下拉菜單）。在這裏它與鍵/值對一起使用。通常這是針對數據的值和displayValue關係完成的。

如果您需要更低級別的對象，請檢查Ext.util.MixedCollection對象。那裏有很多有趣的東西。它基本上是鍵/值對的散列表。我相信Ext源代碼，商店使用這些對象的核心。