在模型与控制器中使用 CoreLocation 的最佳实践

Question

我正在尝试找出构建我的应用程序的最佳方式。我目前有一个围绕 CLLocationManager 的包装类，它将自己设置为委托并处理我们需要的所有额外设置和业务逻辑。它也是一个单例（sharedManager）。

我希望尽可能忠实于 MVC，并在我的模型中加入尽可能多的逻辑，但我不确定实现这一点的最佳方法。目前，控制器和模型都在获取 sharedManager 并在其上调用方法，例如在呈现模式（控制器）之前检查位置是否可用，或者在进行 REST 调用（模型）之前获取当前位置，但这感觉非常耦合且难以测试。

我想尽可能地使用依赖注入来避免在我的代码的所有部分中不断查询单例方法，但我想不出最好的方法。

我的一些想法：

• 将我的 CLLocationManager 包装器转换为使用通知与应用程序的所有部分对话以改进解耦。然后我可以使用单例进行启动/停止调用，但让我的控制器/模型通过收听通知来对更改做出反应。这仍然不能避免到处使用单例。

• 仅在控制器中使用单例，并通过设置属性将所需的位置数据传递给模型。感觉这会让我的模型更容易测试，但不会让我的控制器更容易测试，而且将核心位置代码放在控制器中也感觉很恶心。

• 我可以通过在模型和控制器上设置属性来传递我的自定义位置管理器包装器的实例，但这感觉有点乏味，并且仍然留下了我在哪里创建初始管理器的问题？

我希望能更深入地思考这个问题的人提供一些建议。欢迎和赞赏所有想法！

Answer 1

我想尽可能地使用依赖注入来避免在我的代码的所有部分中不断查询单例方法，但我想不出最好的方法。

你回答你自己的问题：

我可以通过在模型和控制器上设置属性来传递我的自定义位置管理器包装器的实例，但这感觉有点乏味并且仍然留下了我在哪里创建初始管理器的问题？

让你的包装器成为一个单例并没有错，和将它的引用传递给需要它的对象——这是处理依赖注入的一种方法。你可以有很多对象依赖于它的接口，但是如果你不想让它成为一个单例，你也可以这样做。

您的模特不必知道您的位置经理是单身人士。也许只有你的控制器可以。或者，您可以在应用程序中选择一个或几个了解位置管理器的单例性质并将其注入依赖组件的根位置。您希望如何做到这一点在很大程度上取决于您现有的应用程序架构。你可以为它创建一个“查找器”（让它再次变得很像一个单例）或者将它作为构造函数中的参数传递——这是一种有时被忽略的依赖注入方法。

我还建议您查看Key Value Observing，并让您的模型或控制器观察您的位置管理器上的位置属性。我个人也喜欢将Reactive Cocoa 用作“带有块的KVO”库，而不必一头扎进函数式反应式编程。 ReactiveCocoa 可以节省大量与 Objective-C 中非常强大的 KVO 系统相关的headaches。

我不提倡使用通知来传达核心更改，例如单个位置。我曾经让事情变得如此混乱。 Objective-C 程序中的一个常见模式是“messages-leafward/notifications-appward”。

位置管理器包装器中的内容本质上是位置服务。将大量业务逻辑放在这些服务中而不是模型中（这是有意义的）并不是一个坏主意。例如，如果您有围绕位置更改频率传播到 UI 更改或移动阈值的业务逻辑，那么这些可能适用于各种不同的模型。在位置服务中拥有与位置相关的通用业务逻辑确实会使您的模型枯竭。