我正在构建一个iOS客户端应用程序来与现有的后端架构进行交互。为了减少延迟，API调用和有效负载，最好“缓存”客户端模型数据以加快索引速度，然后根据需要对客户端/服务器端进行相应更新。
目前的理论堆栈看起来像这样：
Server Side >>>>>>>>>>>>>>>>> Client Side
-----------------------------------------
PHP >> JSON >> CORE DATA >> UIKit Objects
注意：值得注意的是，iOS客户端本身在内部坚持MVC本质上是一个更大的MVC客户端 - 服务器架构中的“视图”。因此，就像在用户操作之后更新模型或在模型更改后更新视图一样，服务器将需要与客户端更改同步，并且客户端需要与服务器端更改同步。 < / p>
某些情境：
一个。许多不同的数据结构可能会通过管道传递，并且必须动态地构造成UIViews。可能必须定义一个模式（我不确定是否有一种“最好的方法”来遵守JSON模式客户端，而不是记住可接受的对象结构是什么）。我已经意识到需要将与自定义视图（“视图”模型）的创建有关的模型数据与将在这些视图中呈现的内容的模型数据（“常规”模型）分开。
B中。最终用户应该能够立即 CRUD （创建，读取，更新，销毁）这些视图中显示的大多数数据（但不是CRUD视图本身）。他们以后可能需要在Web界面或其他环境中查看它。
℃。 RestKit看起来很适合从API到JSON到COREDATA。当需要将客户端模型副本推送到服务器时，我需要查明它是否在结构上支持回调。也许最好的方法是在发生更改时在客户端模型中注意并通知任何基于RestKit的HTTP管理器将其传递给服务器。
终极问题： 任何人都可以使用这种类型的架构来讨论最佳实践，陷阱，技巧和框架吗？ （特别是在性能和客户端与服务器之间的工作分配方面，但也非常感谢一般建议。）
答案 0 :(得分：1)
我已经做了一些工作，希望我可以提供一些见解。
关于A）是的如果你打算使用CoreData（或RestKit），你需要事先了解你的架构。你将无法映射动态对象，除非你有一些通用对象类型，你只是存放JSON字符串或其他东西，但这听起来不像你正在尝试做的，因为你提到用户编辑那些对象。
B）RestKit将为您处理推送到服务器，但您仍然需要对此进行一些控制。我们通过始终首先在本地保存然后在成功保存时推送到服务器来处理它。这也使我们能够在没有网络的情况下工作。您只需处理服务器拒绝用户正在执行的更新/创建/删除时发生的情况的边缘情况。
C）RestKit可能会让你在80％的路上，就像它为我们做的那样。只是有一些东西来理解REST端点和对象映射，并抽象HTTP请求是一个巨大的帮助。就系统理解变化而言，我们在托管对象上保留了一个标志，以确定对象是否需要同步。我们可以根据这些标志获取并推送服务器。RestKit的一个优点是您可以在CoreData模型中拥有其他属性，这些属性不一定是JSON模式的一部分，但您可能需要在应用程序中使用。例如，我已经提到了用于了解对象是否需要同步的标志。我们还保留了我们用于搜索的预先计算的字段以及一些其他随机信息，用于确定推送到服务器的对象的顺序（依赖性）。
希望这会有所帮助。如果您有更具体的问题，我可能会有更多答案。