Breeze 微风内存管理-模式/实践？

我有一个旧的SL4/ria应用程序，我想用breeze来取代它。我有一个关于内存使用和缓存的问题。我的应用程序加载作业列表（一个典型用户可以访问大约1000个作业）。此外，还有相当多的查找实体类型。我想确保这些都在客户端缓存良好，但每个会话都会更新。当用户打开一个作业时，它会加载更多的相关实体（200-800个其他实体），这些实体构成作业的多个矩阵样式视图。用户可以查看作业列表，或导航到一次查看一个作业

我觉得我应该关注内存管理，尤其是不知道浏览器如何处理这个问题。最初我觉得这应该是一个EntityManager，当用户离开一个工作时，我会分离实体，但我认为这可能会从多个经理的预期寿命中受益。或者，我应该在用户每次导航到新的哈希“/#/”区域时创建一个新的dataservice&EntityManager，因为clear（）上的注释似乎表明这会更快？如果我这样做了，我想我将使用pub/sub通知其他viewmodels对实体的更改？这似乎很复杂，并且破坏了微风作为上下文的一些好处

---

如果您有任何建议或想法，我们将不胜感激。

我想我理解这个问题。我想我会使用多经理方法：

查找管理器-每个会话保留一次引用（查找）实体

JobsView管理器支持JobsView的“只读”作业列表

JobEditor管理器-每个编辑会话一个

查找管理器维护引用实体的规范副本。您可以通过一次对服务器的调用来填充一次（如何填充请参见文档）。此查找管理器将轻松地将这些引用实体导出到其他管理器，这些管理器在创建它们时轻松地导入它们。我假设，尽管参考实体数量众多且种类繁多，但其总内存占用量却相当低。。。足够低，您可以在多个管理器中拥有多个副本。如果不是这样，还有更复杂的解决方案。但现在就这样吧

JobsView管理器具有显示所需的参考实体。若只显示作业的投影，则缓存中不会有作业。您可能有一个数组和键映射。让我们保持简单，假设它拥有所有作业，但没有相关实体

您从未使用此管理器保存更改！在编辑或创建作业时，您的应用程序总是使用自己的VM和作业编辑器管理器启动“作业编辑器”视图。同样，您可以导入所需的引用实体，并且在编辑现有作业时，也可以导入作业

我无论如何都会采取这种方法。。。不仅仅是因为记忆问题。我喜欢将编辑会话隔离到沙盒中。使取消变得容易。为我提供了一种在浏览器存储中存储挂起的更改的干净方法，以便在应用程序/浏览器关闭时用户不会丢失其工作。打开了同时编辑多个作业的大门。。。不用担心相互依赖的实体会发生变化。这是一种经过验证的模式，我们已经在SL应用程序中永久使用，并且应该在JS应用程序中应用

当作业编辑成功时，您必须告诉本地客户机。有很多方法可以做到这一点。如果唯一需要知道的地方是JobsView，您可以将一个反向通道硬编码到应用程序中。如果你想变得更聪明，你可以有一个中心的单例服务，专门引发关于工作节省的事件。JobsView和每个新的JobEditor都与此服务通信。如果你想变得时髦，你可以使用一个进程中的“事件聚合器”（你的发布/订阅）来达到这个目的。无论如何，我可能会使用这个应用程序，它在框中有一个事件聚合器

老实说，使用实体并没有那么复杂，在管理者之间导入/导出实体是一个。。。啊哼。。。微风。与每次返回作业列表时刷新作业列表相比，它是值得的（尽管您也需要一个“刷新按钮”，因为其他用户可能正在添加/更改这些作业）。您保留了许多Breeze的优点：查询、验证、更改跟踪、批量保存、实体导航（这些参考列表在Breeze中“免费”工作）

---

作为改进，我不知道在返回JobsView时会自动销毁JobEditor视图/viewmodel/manager。根据我的经验，人们经常回到刚刚离开的工作岗位。我可能会保留一个视图，这样你就可以快速来回。但现在我变得很棘手。

这是一个很好的回答。谢谢你的描述。我想我还没有真正考虑过编辑生命周期。谢谢你的反馈。沃德，谢谢你。我有一个问题：在像Durandal这样的AMD环境中，难道不可能要求（lookupManager）而不是breeze导出/导入它吗？这会给我带来麻烦吗？当然有可能。不知道它能给你买什么。对于所有性能问题，首先衡量和理解问题的具体内容至关重要，然后才能创造性地提出解决方案。查找数据很容易，但实际问题可能在其他地方（DOM写入、过度事件/监视、未发布的对象、GC抖动）