我正在努力找出构建我的应用程序的最佳方法。我目前有一个围绕CLLocationManager的包装类，它将自己设置为委托并处理我们需要的所有额外设置和业务逻辑。它也是一个单例（sharedManager）。
我希望尽可能忠实于MVC，并将尽可能多的逻辑推入我的模型中，但我不确定这样做的最佳方法。目前，控制器和模型都在获取sharedManager和调用方法，例如在进行模式（控制器）之前检查位置是否可用，或者在进行REST调用（模型）之前获取当前位置，但这种情况非常困难，难以测试。
我想尽可能多地使用依赖注入，以避免在我的代码的所有部分中不断查询单例方法，但我无法找到最佳方法。
我有过一些想法：
转换我的CLLocationManager包装器以使用通知与应用的所有部分通信以改善解耦。然后我可以使用单例进行启动/停止调用，但让我的控制器/模型通过监听通知来对更改做出反应。这仍然无法避免在整个地方使用单身人士。
仅使用控制器中的单例，并通过设置属性将所需的位置数据传递给模型。这感觉它会让我的模型更容易测试，但不是我的控制器，并且将Core位置代码放在控制器中也感觉很蠢。
我可以通过在两个模型和控制器上设置属性来传递我的自定义位置管理器包装器的实例，但这感觉有点单调乏味仍然存在问题，我在哪里创建初始管理器？
我喜欢那些深入思考这个问题的人的一些建议。欢迎并赞赏所有想法！
答案 0 :(得分：2)
我想尽可能多地使用依赖注入，以避免在我的代码的所有部分中不断查询单例方法，但我无法找到最佳方法。
你回答自己的问题：
我可以通过在两个模型和控制器上设置属性来传递我的自定义位置管理器包装器的实例，但这感觉有点单调乏味仍然存在我在何处创建初始管理器的问题？
使包装器成为单例，和将对它的引用传递给需要它的对象没有任何问题 - 这是处理依赖注入的一种方法。你可以拥有很多依赖于它的界面的对象，但是如果你想要退出它是一个单身，你也可以这样做。
您的模型不必知道您的位置管理器是单身人士。也许只有你的控制器。或者，您可以在应用程序中选择一个或几个根位置，了解位置管理器的单例性质并将其注入相关组件。您希望如何做到这一点取决于您现有的应用程序架构。你可以为它创建一个“finder”（使它更像一个单例）或者将它作为构造函数中的参数传递 - 一种有时被忽略的依赖注入方法。
我还建议您查看Key Value Observing，并让您的模型或控制器观察您的位置管理员的位置属性。我个人也喜欢使用Reactive Cocoa作为“KVO with blocks”库，而不必首先进入功能反应式编程。 ReactiveCocoa可以在Objective-C中保存与非常强大的KVO系统相关的大量headaches。
我不主张使用通知来传达像单个位置这样的核心更改。我的事情变得非常混乱。 Objective-C程序中的一个常见模式是“messages-leafward / notifications-appward”。
您的位置管理器包装器中的内容实际上是位置服务。将大量业务逻辑放在这些服务而不是模型中（这是有意义的）并不是一个坏主意。例如，如果您的业务逻辑围绕传播到UI更改的位置更改频率或移动阈值，那么这些逻辑可能适用于各种不同的模型。在位置服务中使用与位置相关的常见业务逻辑可以真正干掉您的模型。