2012-01-30 126 views
3

我正在构建iOS客户端应用程序以与现有的后端架构进行接口。为了减少延迟,API调用和有效载荷,为了加快索引,“缓存”模型数据客户端会很好,然后根据需要相应更新客户端/服务器端。iOS客户端:将服务器端数据“缓存”到永久存储

目前的理论堆栈会是这个样子:

Server Side >>>>>>>>>>>>>>>>> Client Side 
----------------------------------------- 
PHP >> JSON >> CORE DATA >> UIKit Objects 

注:另外值得一提的是,iOS的客户端,同时它本身秉承MVC内部会在本质上是一个“查看”中一个更大的MVC客户端 - 服务器架构。因此,就像在用户操作后更新模型或在模型更改后更新视图一样,服务器需要与客户端更改同步,并且客户端需要与服务器端更改同步。

一些背景:

答:许多不同的数据结构可以过来管道和将要建设成为UIViews动态。一个模式可能必须被定义(我不确定除了记住可接受的对象结构是什么之外,遵守模式客户端是否有“最佳方式”)。我意识到需要将与创建自定义视图(“视图”模型)有关的模型数据与将在这些视图中呈现的模型数据(“常规”模型)分开。 B.最终用户应该能够立即CRUD(创建,读取,更新,销毁)在这些视图中呈现的大多数数据(但不能CRUD视图本身)。他们可能以后需要在Web界面或其他上下文中查看。

C. RestKit看起来很适合从API到JSON到COREDATA。我需要确定它是否需要将客户机模型副本推送到服务器时,它在结构上支持回调。也许最好的方法是在发生更改时在客户端模型中注意并通知基于RestKit的HTTP管理器将其传递到服务器。

终极问题: 任何人都可以谈论最佳实践,陷阱,技巧和框架与这种类型的体系结构? (特别是当涉及到性能和客户端和服务器之间的工作分配,但一般建议也非常感谢。)

回答

1

我已经做了一些工作,希望我能提供一些见解。

关于A)是的,如果你打算使用CoreData(或RestKit),你需要事先了解你的架构。除非你有一些通用的对象类型,你只是在存储JSON字符串或其他东西,否则你将无法映射动态对象,但是这听起来不像你提到编辑那些用户对象。 B)RestKit会处理推送到你的服务器,但你仍然想要一些控制我想象的。我们通过始终先保存在本地,然后在成功保存时推送到服务器来处理它。这也使我们能够在没有网络的情况下工作。您只需处理服务器拒绝更新/创建/删除用户正在执行时发生的情况的边缘情况。

C)RestKit可能会为您提供80%的方式,就像它为我们做的那样。只需要理解REST端点和对象映射,并且抽象HTTP请求是一个巨大的帮助。就系统理解变化而言,我们在托管对象上保留了一个标志,以确定对象是否需要同步。我们可以基于这些标志提取并推送服务器。

RestKit的一件事是您可以在CoreData模型中拥有其他属性,这些属性不一定是JSON模式的一部分,但您可能需要在您的应用程序中使用。例如,我已经提到知道某个对象是否需要同步的标志。我们还保留了我们用来搜索的预先计算的字段以及其他一些随机信息,以确定推送到服务器的对象顺序(依赖关系)。

希望这会有所帮助。如果你有更具体的问题,我可能会有更多的答案。