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