不是Dagger 2 for Android不是DI框架,而是美化服务定位器？

Question

例如,假设使用Retrofit创建的Rest适配器位于Application类中.我很想把它放在Activity中,所以我写下面的代码:

public class MainActivity extends Activity {
    @Inject MyRestAdapter mRestAdapter;

    @Override 
    public void onCreate(Bundle savedInstanceState) {
        super.onCreate(savedInstanceState);
        ((GlobalApplication) getApplication()).getComponent().inject(this);
    }
}

当然,它将完成工作.但是......这与调用getApplication()有什么不同,然后明确地将MyRestAdapter拉到MainActivity？是的,Dagger 2将通过自动将所有内容都添加到Activity来简化设置,但是您仍然需要明确告诉您需要这些依赖项的位置,并且如果我理解正确,则会破坏DI的整个目的.我是否正确地说Dagger 2是"半自动服务定位器",或者它只是误导我的教程,并且有正确的方法将Dagger 2的依赖注入到View或Activity from Application中？

Answer 1

我一直在尝试 Dagger，它似乎模糊了服务定位器和依赖注入之间的界限。至少在与 Android 活动一起使用时是这样。使用当前版本的 Dagger，可以写入AndroidInjection.inject(this)活动的onCreate方法。这基本上就像在说“找到我需要的所有服务并将它们注入我体内”。因此，Dagger 是一个知道从哪里获取服务的中央/全局服务定位器和一个知道将这些服务放在活动中的位置（即哪些实例变量）的注入器的组合。Android 活动似乎强制依赖某种单例/全局对象。

Answer 2

没有 1 个“DI 的目的”，但其中之一肯定是将配置与实际请求配置对象的内容分开。这个想法是，您的更高级别对象（例如ActivityAndroid 中的 s）可以请求它需要的所有对象，而不必担心它们来自哪里、如何构造以及有关它们关系的任何语义。类似于 anActivity不处理在屏幕上绘制文本的方式（而是将其委托给 aTextView（而是将其委托给[0]），DI 有助于防止您的对象了解太多与它们需要执行的实际逻辑无关的信息。

您描述的“半自动服务定位器”固有的是静态分析和错误处理。随着应用程序变得越来越大，手动 DI 的正确性变得更加困难。Dagger 有助于使您的代码不易出错（并且维护起来不那么繁琐）。

考虑一下这样的情况：您有一个供员工使用的内部版本的应用程序，您在其中记录了有关他们如何使用该应用程序的大量信息，以确保您可以识别任何问题。然而，在您的实际产品中，如果没有必要，您不希望跟踪这样的个人身份信息。现在，您MainActivity需要AnalyticsLogger- 应该得到哪一个？您拥有的案例越多，Dagger 帮助您将事情拼凑起来比您自己做就越容易。

[0] 委托给一个Paint对象