谁应该在iOS应用程序中拥有Dependency Injected对象？

Question

对于经验丰富的iOS开发人员来说,这可能是一个基本问题,但是来自Java背景,我们有许多依赖注入(DI)好东西(即Spring),我在确定谁应该拥有DI对象时遇到一些麻烦.不幸的是,我发现自己创造了一堆单身人士,这对于管理变得非常讨厌.

例如,我们有一些Configuration其他类想要访问的.目前我们只有一个Configuration的单例实例,这使得测试有点困难.从技术上讲,我们使用OCMock中的方法调配来克服这个问题.

在Java/Spring中,有一些容器可以创建/拥有这些对象.在iOS中,我认为我对容器最接近的是UIApplication和UIApplicationDelegate.这些东西是否有意义创建/拥有最终会被注入其他对象的这些对象？

如果是这样,访问这些对象的适当策略是什么？例如,在UIApplication或UIApplicationDelegate上创建一个类别来访问这些对象,如: [[UIApplication sharedApplication] configuration]或[[[UIApplication sharedApplication] delegate] configuration]

Answer 1

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

来自Objection的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 方法中创建所有服务。