我记得阅读开发人员应该将商店中的记录视为数据库中的一行，其中每列是一种简单的数据类型。我们在Ext JS商店中存储复杂的JS对象，没有任何明显的后果。
有没有人知道将JS对象存储在Ext JS商店中的陷阱？
答案 0 :(得分：3)
现代网络浏览器已经非常擅长管理这种内存使用和处理速度。在内部，我们实现了extjs 4现在内置的那种记录关联，并且存储了大约250k个复杂嵌套记录的场景，没有任何实际问题。我相信对性能影响微不足道的影响会持续很长时间，因为它本身就可以很好地清理自己的内存使用量。我们将我们的Web服务器的ORM模型镜像到extjs记录定义，并定期查询这些嵌套存储，其方式与我们访问更传统的数据库的方式大致相同。你必须小心你用它做什么，例如，尝试一次渲染250k记录的网格将不会很好。但这几乎完全是dom渲染的影响，而不是记录/存储数据的迭代或存储。在使用最近的extjs 4测试版发布测试时，所有这一切似乎更加真实。
答案 1 :(得分：2)
查看Ext JS源代码，Store似乎是Object的包装器，提供排序/过滤器和事件功能。这是一个简单的键/值对。
对象的复杂性不应该导致任何问题。
现在将Store视为除了键/值对集合的包装之外的任何东西都会导致问题。认为它就像一张桌子会导致问题。这种误解会导致代码设计不佳。
应将Store视为一袋关键/价值数据，并使用辅助方法来整理该行李。
答案 2 :(得分：1)
我认为如果你的JS对象非常庞大，可能会对性能产生影响，如果最终对这些JS对象进行大量的序列化/反序列化，可能需要一些时间。如果您正在处理网格，可以使用分页来缓解这些问题。
商店不一定严格用于网格行。它们用在许多Ext对象中，例如组合框（下拉菜单）。这里它与键/值对一起使用。通常，这是针对数据的值和displayValue关系完成的。
如果需要更低级别的对象，请查看Ext.util.MixedCollection对象。那里有很多有趣的东西。它基本上是键/值对的散列图。我相信Ext源代码，Stores使用这些对象作为核心。