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