ios - 如何处理 Web 服务和数据模型/ Controller

Question

我正在将 SOAP 与 wsdl2objc 生成的代码一起使用。我有多个 View Controller 需要共享 Web 服务提供的数据。我想要一个数据模型部分，但我很难看到如何处理这个问题。当然，调用应该是异步的。我的问题是，最好的做法是什么？谁应该负责获取数据？谁应该存储数据？如何处理并发？任何想法将不胜感激!

更新:
我正在考虑使用 CoreData，但不确定当数据频繁更新时是否有什么好处。我最大的问题是如何处理 View Controller 从模型请求数据但没有数据可用的场景。这意味着执行一个缓慢的 Web 服务调用并以某种方式在数据进入时通知 View Controller 。通知中心是通往这里的方式吗？流量如何？ View Controller 是否应该不断监听更新通知？我的想法是， View Controller 注册为观察者，使用模型中的数据填充 View (无论是空数据)，并自动更新收到的通知，即从现在具有“最新”数据的模型中获取数据可用。将所有网络调用都排除在 View Controller 之外，允许 View Controller 访问共享数据。想法？

Answer 1

在您更新的问题中，是的，我认为通知中心是后台网络任务在新数据可用时更新 View Controller 的完美方式。
你问:

should the view controllers constantly be listening for update notifications?

有点。术语“不断地倾听”可能意味着它不断地检查更新。显然，它并没有真正这样做(或者，更重要的是，您不希望它这样做)。相反，它只是将自己注册为该通知的观察者(并确保当 View 被解除时，它也会取消注册自己)。这样，它会收到您的任何自定义通知的通知，但不会浪费大量 CPU 周期“不断地监听”。
然后你跟进并询问:

My thoughts are, that a view controller registers as an observer, populates the view with data from the model (regardless of empty data), and automatically updates on received notifications, i.e. fetches the data from the model which now has the "newest" data available. That leave all network call out of the view controllers, allows the view controllers to access shared data. Thoughts?

基本上，是的，这听起来不错。我对此的唯一细微改进是，我将使用将应用程序发布到商店时的最新数据预先填充应用程序数据库。这样，当应用程序检索最新数据时，用户可以查看一些内容。也许这在您的场景中无效，但通常最好向用户展示一些东西(即使有点过时)，而不是什么都不展示，同时应用程序检索最新和最好的。
最后(你可能已经在考虑这个了)，我会确保你向用户展示了一些数据正在后台下载的视觉指示。或许是一个位置优越的 UIActivityIndicatorView (即旋转器)或 UIProgressView .也许更新 UIRefreshControl 的文本如果您正在处理表格 View ，则说明下载正在进行中。也许也更新状态栏中的网络事件指示器。

我相信每个人都有自己的方法，但这里有一些关于我在应用程序中所做的事情的一些观察，数据检索过程很复杂，完全异步发生，并且应用程序可以在下载/处理过程中正常进行:

除了标准模型、 View 和 View Controller 类之外，我还有一个单独的“xml Controller ”来下载和解析结果。我让它异步启动下载。

为了促进 xml Controller 和 View Controller 之间的通信，我使用了通知。这样，xml Controller 将发布有关下载/解析过程的开始和完成特定阶段的通知。如果 View Controller 在更新过程中不可靠，则 View Controller 可以选择在开始时呈现微调器，和/或仅在特定下载/解析阶段完成后相应地刷新自己。必须小心谨慎才能真正识别所有应用层并发问题。在每一步中，您都必须处理“如果后台队列中的模型数据发生更改会怎样”的逻辑场景。
最重要的是，在进行异步更新时，防御性编程是日常规则。你永远无法做出假设，仅仅因为你最近检索了一些即使在片刻之后它仍然有效的东西。我们在代码中随意做出的许多假设不再成立。我也会对基于某个索引(例如“第 5 项”)的任何操作更加谨慎，并且绝对倾向于基于键的操作(例如“具有 4027 唯一标识符的项”)。

就数据库层并发问题而言，它在一定程度上取决于持久存储的性质。如果您使用的是 Core Data，请查看 WWDC 2012 - 214 Best Practices with Core Data其中讨论了并发性。或查看 Concurrency with Core Data在核心数据编程指南中。如果使用 SQLite，一个简单的解决方案是为数据库操作建立一个专用的串行队列，例如 FMDB's FMDatabaseQueue .顺便说一下，如果您使用后一种方法，您需要确保将数据库交互分解为尽可能小的操作，以避免占用数据库。

如果您想让用户了解异步下载/更新过程的进度，您可能需要考虑您的框架。一些应用程序会做一些简单的事情，比如状态栏中的网络事件指示器。其他人在一些公共(public)导航栏中更新一些状态消息。我还为我的通知使用了一个自定义容器，这样我就不必在每个 View Controller 中添加“显示用户状态更新”。这里有一堆方法，但您可能应该避免需要在每个 View Controller 中包含状态更新代码的解决方案(显然，如果 View Controller 依赖于后台队列正在修改的当前项目，则在在这种情况下，这不是状态更新问题，而是应用程序流程问题)。