谁应该拥有 iOS 应用程序中的依赖注入对象？

Question

对于经验丰富的 iOS 开发人员来说，这可能是一个基本问题，但是来自 Java 背景，我们有很多依赖注入 (DI) 好东西（即 Spring），我在弄清楚谁应该拥有 DI 对象时遇到了一些麻烦。不幸的是，我发现自己创建了一堆单例，这变得非常难以管理。

例如，我们有一些其他类想要访问的Configuration。目前我们只有一个配置实例，这使得测试有点困难。从技术上讲，我们使用 OCMock 中的方法调配解决了这个问题。

在 Java/Spring 中，有一些容器创建/拥有这些对象。在 iOS 中，我认为最接近容器的是 UIApplication 和 UIApplicationDelegate。对于这些东西来说，创建/拥有这些最终将被注入到其他对象中的对象是否有意义？

如果是这样，访问这些对象的适当策略是什么？例如，在 UIApplication 或 UIApplicationDelegate 上创建一个类别来访问这些对象，例如： [[UIApplicationsharedApplication]配置]或[[[UIApplicationsharedApplication]委托]配置]

Answer 1

我开始评估一个名为 Objection 的 Objective-C DI 框架。它的灵感来自于 Java 版的 Google Guice。

反对的 README 中的示例用法

@class Engine, Brakes;

@interface Car : NSObject
{
  Engine *engine;
  Brakes *brakes;
  BOOL awake;  
}

// Will be filled in by objection
@property(nonatomic, retain) Engine *engine;
// Will be filled in by objection
@property(nonatomic, retain) Brakes *brakes;
@property(nonatomic) BOOL awake;

@implementation Car
objection_register(Car)
objection_requires(@"engine", @"brakes")
@synthesize engine, brakes, awake;
@end

Answer 2

事实上，DI 似乎并不是人们通常在 iOS 中使用的东西，就像我们在 Java 或 C# 中所做的那样。

就我个人而言，我倾向于创建自己的单例，称为应用程序，它保存应用程序的所有服务和信息。通过这种方式，我获得了简单单例的简单性，而无需专门附加到 iOS（即使 obj-c 几乎不能在其他任何地方使用）。因此，在我的应用程序中，我通常有：

[[Application sharedInstance] configuration]
[[Application sharedInstance] authService]

因此，唯一需要成为单例的类是 Application 类（与 UIApplication 无关），它在 init 方法中创建所有服务。