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的Java。

来自异议的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＃中所做的那样。

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

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

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

2 个答案:

来自异议的README