Question

我是依赖注入模式的忠实粉丝，但在移动开发中遵循这种模式并且主要原因是内存分配时，我有点怀疑。我将简要解释一下我的担忧：

我在基于Objective-C的iOS项目中使用DI。我已经使用了Objection和Typhoon，但却无法找到一种懒惰地实例化依赖关系的方法（不是专门讨论Singletons）。即使应用程序的用例流不需要分配对象，我也会注入依赖项。一旦我调用injectDependencies:方法（异议）或plist Integration（Typhoon），就会注入所有依赖关系。虽然异议网站提到它懒散地加载了所有东西，但我没有看到证据。有没有办法使用这些框架延迟加载依赖项？例如，我想要这样的东西：

@property (nonatomic) MyClass *classObject;

- (void)viewDidLoad
{
    [super viewDidLoad];

    // Check at this point that classObject should be nil

    id str = classObject.myString;

    // As soon as the getter is called, the property is first instantiated and then returned a value.
}

DI意味着这样吗？如果是，那么这种模式是否会违反移动设备的内存分配拇指规则（仅在您需要时分配）？

Answer 1

Typhoon创始人在这里。

服务器端项目的依赖注入

当我们在服务器端框架中使用依赖注入时，默认范围是单例。这是有道理的，因为可以期望服务器在给定时间点服务于任何用例。

移动和桌面上的依赖注入

在iOS中，我们可能有一些后台（单例）组件，但我们通常一次只关注一个用例。因此， Typhoon在其scopes中引入了唯一的TyphoonScopeObjectGraph作为默认 。

使用TyphoonScopeObjectGraph表示描述了依赖关系之间的关系，Typhoon将仅在对象图解决时创建共享实例。这意味着您可以使用循环依赖关系（委托模式）等连接复杂的对象图。然后台风将整个对象图交给任何将要使用它的东西，并释放所有权。

正常的Objective-C运行时规则从此处应用 - 如果控制器或使用构建的对象图的任何内容具有强属性，则只要该视图控制器，图形将保留在内存中。

通过这种方式，我们可以从一个对象图（用例）继续到另一个，同时保留资源受限设备上的内存。

其他范围

除了默认值之外，Typhoon还包括以下附加范围：

TyphoonScopeSingleton - 由DI容器保留。用于后台守护进程等。
TyphoonScopeLazySingleton - 与常规单例一样，但实例化会延迟到第一次使用时。（我相信异议单身人士就是这样工作的）。
TyphoonScopeWeakSingleton - 实例化并共享，只要至少有一个对象保留它，然后销毁。将在下次再次请求时重新实例化。
TyphoonScopePrototype - 即使在单个求解周期中，也始终创建一个新实例。

从一个对象图表转到另一个：

台风建造的故事板可以加载另一个对象图，例如另一个视图控制器，以“按需”进入新的用例。为此，我们将Typhoon作为工厂类，并inject the assembly itself，可选。然后我们可以让Typhoon构建所需类的实例。如果您希望可以使用协议支持您的程序集，那么您的课程不会直接与Typhoon相关联。

懒惰地在iOS中使用DI实例化依赖关系（Typhoon＆amp; Objection）

1 个答案: