我是却把清梅嗅,一个普通的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迁移至Kodein的感受
有些时候,Dagger2可能会有点过于复杂。 例如,当每个 Activity 都有一个 Scope(作用域) 时,每个屏幕都必须实现一个Scope,一个Module和一个Component。
对于Kotlin的开发者来讲,Kodein将是你的救星。
1.Kodein并不是一个依赖注入(DI)框架
虽然 Kodein 全名为 KOtlin DEpendency INjection,但Kodein并不是一个真正的依赖注入框架。 他们的官方文档将其称作 依赖检索容器 。
Kodein使用容器来传递依赖关系,这与Dagger2有什么不同? 让我们看一下从文档的Kodein示例代码:
val kodein = Kodein { bind<Dice>() with provider { RandomDice(0, 5) } bind<DataSource>() 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<Dice> with provider { RandomDice(0, 5) }}val foo = Kodein { bind<UserRepository> with singleton { UserRepo() }}
如果你很幸运,不小心将foo而不是kodein传递给一个对象。 该项目将成功编译,但它将在运行时发生崩溃。
还有?
我喜欢在这个小项目中使用Kodein。 我认为它的DSL非常简单,功能强大且简洁。 但我确实遇到了只在运行时捕获的问题。
我可能会在小项目上再次使用Kodein。 对于更大的项目,我可能还是需要保持观望的态度。
作者:却把清梅嗅
链接:https://www.jianshu.com/p/e5eef49570b9
来源:简书
著作权归作者所有。商业转载请联系作者获得授权,非商业转载请注明出处。