ExtJS存储和复杂对象

现代web浏览器已经非常善于管理这种内存使用和处理速度。在内部，我们已经实现了extjs 4现在内置的那种记录关联，并且在场景中存储了大约250k个复杂的嵌套记录，没有任何实际问题。我相信，对性能的微不足道的影响将持续很长一段时间，因为它在清理自己的内存使用量方面也很好。我们将web服务器的ORM模型镜像到extjs记录定义中，并以与使用更传统的数据库相同的方式定期查询这些嵌套存储。你必须小心处理它，例如，试图一次渲染25万条记录的网格不会很好。但这几乎完全是dom渲染的影响，而不是记录/存储数据的迭代或存储。当使用最近的extjs4测试版进行测试时，所有这些似乎都更加真实。

从ExtJS源代码来看，Store似乎是Object的包装器，它提供排序/筛选和事件功能。这是一个简单的键/值对。

对象的复杂性不应该引起任何问题。

现在，将Store视为键/值对集合的包装之外的任何东西都会导致问题。认为这就像一张桌子会引起问题。这种误解会导致代码设计不当。

Store应被视为一个关键/价值数据包，并使用辅助方法来组织该数据包。

我认为如果你的JS对象很大，可能会对性能产生影响，如果你最终对这些JS对象进行了大量的序列化/反序列化，可能需要一些时间。如果您正在处理网格，您可以通过使用分页来减轻这些问题。

存储不一定严格用于网格行。它们用于许多Ext对象，如组合框(下拉菜单(。在这里，它与键/值对一起使用。通常，这是对值和数据的displayValue关系进行的。

如果需要使用更低级别的对象，请检出Ext.util.MixedCollection对象。里面有很多有趣的东西。它基本上是一个键/值对的散列映射。我相信Ext的源代码，Stores在其核心使用这些对象。