我有一个旧的 SL4/ria 应用程序，我希望用微风取代它。我有一个关于内存使用和缓存的问题。我的应用程序加载工作列表（一个典型的用户可以访问大约 1,000 个这些工作）。此外，还有很多查找实体类型。我想确保这些在客户端缓存得很好，但每个会话都会更新。当用户打开作业时，它会加载更多相关实体（从 200 到 800 个附加实体），这些实体构成作业的多个矩阵样式视图。用户可以查看作业列表，或导航到一次查看 1 个作业。
我觉得我应该关注内存管理，尤其是不知道浏览器如何处理这个问题。最初我觉得这应该都是 1 EntityManager 并且当用户离开工作时我会分离实体，但我认为这可能会在预期的生命周期内受益于多个经理。或者，每次用户导航到新的哈希“/#/”区域时，我应该创建一个新的数据服务和实体管理器，因为对 clear() 的评论似乎表明这会更快？如果我这样做了，我想我将使用 pub/sub 来通知其他视图模型对实体的更改？这似乎很复杂，并且破坏了轻风作为上下文的一些好处。
任何有关此的提示或想法将不胜感激。
我想我理解这个问题。我想我会使用多经理方法：
查找管理器维护参考实体的规范副本。您可以通过对服务器的一次调用来填充它一次（请参阅文档了解如何）。这个查找管理器会将这些参考实体微风导出到其他管理器，这些管理器在创建它们时微风导入它们。我假设，虽然数量众多且种类繁多，但引用实体的总内存占用量非常低……足够低，以至于您可以负担得起在多个管理器中拥有多个副本。如果不是这样，还有更复杂的解决方案。但暂时就这样吧。
JobsView Manager 具有显示所需的参考实体。如果您只显示作业的投影，则缓存中不会有作业。您可能有一个数组和键映射。让我们保持简单，假设它拥有所有的 Jobs，但没有它们的相关实体。
您永远不会使用此管理器保存更改！编辑或创建作业时，您的应用程序始终会使用自己的 VM 和 JobEditor Manager 启动“作业编辑器”视图。同样，您导入所需的参考实体，并且在编辑现有作业时，您也导入了作业。
无论如何我都会采用这种方法......不仅仅是因为内存问题。我喜欢将我的编辑会话隔离到沙箱中。轻松取消。为我提供了一种在浏览器存储中存储待处理更改的简洁方式，以便在应用程序/浏览器出现故障时用户不会丢失他/她的工作。打开同时编辑多个作业的大门......而不必担心相互依赖的实体与变化。这是一种经过验证的模式，我们在 SL 应用程序中一直使用它，并且应该也适用于 JS 应用程序。
当 Job 编辑成功时，您必须告诉本地客户端世界。有很多方法可以做到这一点。如果唯一需要知道的地方是 JobsView，您可以将反向通道硬编码到应用程序中。如果你想更聪明一点，你可以有一个中央单例服务，它专门引发关于工作节省的事件。JobsView 和每个新的 JobEditor 都与该服务进行通信。如果你想变得时髦，你可以使用一个进程内的“事件聚合器”（你的发布/订阅）来达到这个目的。无论如何，我可能会在这个应用程序中使用Durandal，并且它在框中有一个事件聚合器。
老实说，在经理之间使用和导入/导出实体并不是那么复杂……咳咳……轻而易举。与每次返回时刷新作业列表相比，这是非常值得的（尽管您也需要一个“刷新按钮”，因为其他用户可能正在添加/更改这些作业）。您保留了 Breeze 的许多优点：查询、验证、更改跟踪、批量保存、实体导航（这些参考列表在 Breeze 中“免费”工作）。
作为改进，我不知道当我返回 JobsView 时会自动销毁 JobEditor 视图/viewmodel/manager。以我的经验，人们经常回到他们刚离开的同一个工作。我可能会保留一个视图，以便您可以快速来回走动。但现在我变得棘手了。