Android开发从Dagger2迁移至Kodein的感受

原文：From Dagger2 to Kodein: A small experiment
作者：Allan Yoshio Hasegawa
译者：却把清梅嗅

译者说

---

我是却把清梅嗅，一个普通的Android开发者。去年，我写了一系列关于Android开发者依赖注入框架 Dagger2 及 dagger.android 的博客：

Android 神兵利器Dagger2使用详解（一）基础使用
Android 神兵利器Dagger2使用详解（二）Module&Component源码分析
Android 神兵利器Dagger2使用详解（三）MVP下的使用
Android 神兵利器Dagger2使用详解（四）Scope注解使用及源码分析
告别Dagger2模板代码：dagger.android使用详解
告别Dagger2模板代码：dagger.android原理分析

最近个人在尝试构建 Kotlin版本 的Android MVVM开发框架，在依赖注入框架的选型上，我最终选择了 Kodein 。

这是一个非常轻量级的DI框架，相比于配置繁琐的Dagger（繁琐的配置也是导致Dagger学习成本一直居高不下的原因！），它的配置过程更清晰且简单，并且，这个库的源码也是 Kotlin 的。

有同学说，虽然 Dagger2 配置很繁琐，但 dagger.android 已经大大减少了模板代码的配置。确实如此，但它终究是通过编译器自动生成 Java 代码的库，我已经厌倦使用它了……请不要再劝我将它掺入 Kotlin 的项目中了。

扯了这么多，请阅读正文吧, 作者简单阐述了 Kodein 的使用感受，通过和 Dagger2 对比，阐述库本身的优缺点，希望能给同行一些参考。

不久之后，我会专门写一篇文章剖析Kodein的 入门教程 和 项目中的应用 ,敬请期待。

2018.9追加

Kodein的中文博客详解已更新：

告别Dagger2，Android的Kotlin项目中使用Kodein进行依赖注入

正文

---

从Dagger2迁移至Kodein的感受

有些时候，Dagger2可能会有点过于复杂。 例如，当每个 Activity 都有一个 Scope（作用域） 时，每个屏幕都必须实现一个Scope，一个Module和一个Component。

对于Kotlin的开发者来讲，Kodein将是你的救星。

1.Kodein并不是一个依赖注入（DI）框架

虽然 Kodein 全名为 KO**tlin *DE**pendency **IN**jection，但Kodein并不是一个真正的依赖注入框架。 他们的官方文档将其称作 依赖检索容器* 。

Kodein使用容器来传递依赖关系，这与Dagger2有什么不同？ 让我们看一下从文档的Kodein示例代码：

val kodein = Kodein {
    bind() with provider { RandomDice(0, 5) }
    bind() with singleton { SqliteDS.open("path/to/file") }
}
class Controller(private val kodein: Kodein) {
    private val ds: DataSource = kodein.instance()
}

第一个表达式创建了一个容器，然后将容器传递给Controller。这之后，将检索依赖项的工作 委托 给了Controller。

而使用Dagger2，该示例将如下所示：

Dagger2中没有 容器 的概念。 依赖关系通过构造函数，属性或方法注入。 Controller不知道dataSource的来源——这是Dagger2和Kodein之间的根本区别。

2.Kodein中可以使用“非常简单易读的声明性DSL”

官方文档是这样描述的， 上面的代码示例也正是这样做的。 它的好处是使代码更加紧凑，嗯，仅此而已 :)

3.使用了Kodein的开源项目？

网上有大量资料可供学习Dagger2：教程，博客文章，开源项目; 它们非常有用。

对于Kodein？ 并不多?我仍然有很多关于如何正确使用Kodein的疑问。

4 Kodein有很多方式可以实现依赖注入

以上文的代码为例，如下所示：

val kodein = Kodein { ... }
class Controller(val dataSource: DataSource)

val controller = kodein.newInstance { Controller(instance()) }

现在Controller不依赖于一个容器，这更类似Dagger2通过构造函数传递依赖关系的的实现方式。

或者我们可以这样做：

val kodein = Kodein { ... }
class Controller {
    private val injector = KodeinInjector()
    private val dataSource: DataSource by injector.instance()

    init {
        injector.inject(kodein)
        // use dataSource
    }
}

这类似于Dagger2注入属性的实现方式。

而且，如果你“勇敢”地在你的应用程序中滥用反射，你甚至可以将JSR330与Kodein一起使用。

关键是，Kodein提供了许多注入依赖关系的方法， 您不必总是将容器传递给对象。

5.你的类可能依赖于Kodein

在使用Dagger2的项目中，您的类将取决于JSR330标准的注解（译者注，@Inject等注解）。 这些类并不依赖Dagger2。

在使用Kodein的项目中，您的类可能需要依赖于Kodein; 这一切都取决于使用哪种实现方式。 在第一个示例中，Controller依赖于Kodein容器。 在注入器示例中，Controller依赖于KodeinInjector。

6.Kodein在运行时判断依赖关系

如果您忘记将实例绑定到容器，则只会在运行时收到错误消息。 而使用Dagger2，您在编译时会收到错误。

7.Kodein容器太通用了

在Dagger2中，我们在定义好的方法中声明模块和组件。 它们可以让Contract了解到谁被谁依赖，依赖被注入在哪里。

但是，Kodein容器没有提供或保存的任何类型信息。 这意味着，对于类型系统，这两个容器是相同的：

val kodein = Kodein {
        bind with provider { RandomDice(0, 5) }
}
val foo = Kodein {
        bind with singleton { UserRepo() }
}

如果你很幸运，不小心将foo而不是kodein传递给一个对象。 该项目将成功编译，但它将在运行时发生崩溃。

还有？

我喜欢在这个小项目中使用Kodein。 我认为它的DSL非常简单，功能强大且简洁。 但我确实遇到了只在运行时捕获的问题。

我可能会在小项目上再次使用Kodein。 对于更大的项目，我可能还是需要保持观望的态度。