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

Question

我有一个旧的 SL4/ria 应用程序，我希望用 Breeze 取代它。我有一个关于内存使用和缓存的问题。我的应用程序加载工作列表(一个典型的用户可以访问大约 1,000 个这些工作)。此外，还有很多查找实体类型。我想确保这些在客户端缓存得很好，但每个 session 都会更新。当用户打开作业时，它会加载更多相关实体(从 200 到 800 个附加实体)，这些实体构成作业的多个矩阵样式 View 。用户可以查看作业列表，或导航到一次查看 1 个作业。

我觉得我应该关注内存管理，尤其是不知道浏览器如何处理这个问题。最初我觉得这应该都是 1 EntityManager 并且当用户离开工作时我会分离实体，但我认为这可能会在预期的生命周期内受益于多个经理。或者，每次用户导航到新的哈希“/#/”区域时，我应该创建一个新的数据服务和实体管理器，因为对 clear() 的评论似乎表明这会更快？如果我这样做了，我想我将使用 pub/sub 来通知其他 View 模型对实体的更改？这似乎很复杂，并且抵消了轻风作为上下文的一些好处。

对此的任何提示或想法将不胜感激。

Answer 1

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

1. 查找管理器 - 每个 session 保存一次引用(查找)实体
2. JobsView 管理器 - 支持 JobsView 的“只读”作业列表
3. JobEditor Manager - 每个编辑 session 一个。

查找管理器维护引用实体的规范副本。您可以通过对服务器的一次调用来填充它一次(请参阅文档了解如何)。此查找管理器会将这些引用实体Breeze-export 到其他管理器，这些管理器在创建它们时Breeze-import。我假设，虽然数量众多且种类繁多，但引用实体的总内存占用量非常低……足够低，以至于您可以负担得起在多个管理器中拥有多个副本。如果不是这样，还有更复杂的解决方案。但暂时就这样吧。

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

您永远不会使用此经理保存更改!编辑或创建作业时，您的应用程序始终会使用自己的 VM 和 JobEditor Manager 启动“作业编辑器” View 。同样，您导入所需的引用实体，并且在编辑现有作业时，您也导入了作业。

无论如何我都会采用这种方法......不仅仅是因为内存问题。我喜欢将我的编辑 session 隔离到沙箱中。轻松取消。为我提供了一种在浏览器存储中存储待处理更改的简洁方式，以便在应用程序/浏览器出现故障时用户不会丢失他/她的工作。打开同时编辑多个作业的大门......而不必担心相互依赖的实体与变化。这是一种经过验证的模式，我们一直在 SL 应用程序中使用，并且应该也适用于 JS 应用程序。

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

老实说，在经理之间使用和导入/导出实体并没有那么复杂……咳咳……轻而易举。与每次返回时刷新作业列表相比，这是非常值得的(尽管您也需要一个“刷新按钮”，因为其他用户可能正在添加/更改这些作业)。您保留了 Breeze 的许多优点:查询、验证、更改跟踪、批量保存、实体导航(这些引用列表在 Breeze 中“免费”工作)。

作为改进，我不知道当我返回 JobsView 时会自动销毁 JobEditor View /viewmodel/manager。以我的经验，人们经常回到他们刚离开的同一个工作。我可能会保留一个 View ，以便您可以快速来回走动。但现在我变得棘手了。