1

我正在开发一个基本上是服务器端 REST API 客户端的应用程序。

该应用程序严重依赖服务器数据（有点像 Facebook 所做的）。

在我的应用程序中，我有一个 ServerAPI 类来管理与服务器的所有交互。它基本上充当“模型-视图-控制器-存储”模式中的“存储”。应用程序的其余部分使用此类的单例实例来访问数据。

因此，例如，如果我的一个视图控制器需要一个文章列表，它会调用：

[[ServerAPI sharedAPI] fetchArticlesWithCompletion:^(NSArray *articles){
    // Do something with the new articles.
}];

这样，应用程序就不会关心文章是如何获取的。据它所知，它们是从本地文件而不是服务器中获取的。

这一切都很好。

现在的问题是我想添加某种缓存。环顾四周后，听起来 Core Data 可能是这项工作的最佳工具（但我绝对愿意接受其他建议）。

我发现 AFIncrementalStore（AFNetworking 的 NSIncrementalStore 子类）看起来很有希望。但是根据我（目前有限）对 NSIncrementalStore 的理解，应用程序（视图控制器）仍然直接与 NSFetchRequests 和 MOC 交互以获取数据。

我想保留我当前的 API（ServerAPI 单例）并简单地在“幕后”插入 Core Data，这样应用程序的其余部分就不会知道细节。基本上，应用程序不应该知道数据被缓存，或者它是如何被缓存的，它应该只是请求数据并获取数据。

所以我的问题是，实施这个的好策略是什么？有没有人做过这样的事情？值得付出努力吗？我知道 Core Data 本身就是一种抽象存储的方式，因此拥有第二层抽象可能是矫枉过正。但是我一直在想如果有一天我决定使用 NSCoding 而不是 Core Data 将对象存储到磁盘的情况。我通常不喜欢让我的所有课程都知道实现细节（在这种情况下使用核心数据而不是不使用核心数据）。

我对哪种方法最好感到有些不知所措。我不想在从长远来看可能没有意义的解决方案上投入太多时间。

一般来说，直接在代码中使用 Core Data API 有意义吗？或者最好在处理服务器和本地数据的自定义 DataManager 后面抽象出所有这些细节。

想法？

4

1 回答 1

0

就个人而言，我会RestKit用作 RESTful API 和 Core Data 之间的桥梁。我会使用 Core Data 并且我不会认为NSCoding将来更改为可能是一个好主意（这是一个非常不可能的情况）。Core Data 为您提供了许多用于存储、搜索和内存管理的选项。从另一家商店获得相同的功能将需要付出很多努力或类似程度的依赖。

无论哪种方式，您都有 2 个选项 - 隐藏缓存或不隐藏。

如果你隐藏它，副作用是你真的需要调用完成块两次（第一次是缓存命中，第二次是服务器响应）。这将是多么容易取决于你在做什么。问题是您将无法利用缓存的所有搜索和内存管理功能（例如仅从存储加载数据页面并在用户滚动列表时加载更多数据）。

如果你不隐藏它，是的，你会使用获取请求和 MOC。可能通过NSFetchedResultsController. 恕我直言，影响相对较小，好处很大（如自动页面管理）。现在您的结构是 - 视图控制器监视数据的“缓存”（ServerAPI拥有 MOC，因此它仍然调解存储），他们可以立即获取现有数据，如果他们决定需要新数据，他们会调用ServerAPI. 它的ServerAPI工作方式与现在完全一样（使用完成块），完成块要么用作更新 UI 活动指示的触发器，要么用作实际的数据源（如果需要）。

正如您可能知道的那样，我会毫不犹豫地使用 Core Data 并允许在我的视图控制器中使用它的功能。我对屏蔽其余代码感兴趣的部分是服务器 API，而不是本地数据缓存。

于 2013-05-12T06:39:22.397 回答