为什么将 Dagger 与 Android 架构组件一起使用答案

【问题标题】：Why use Dagger with Android Architecture Components为什么将 Dagger 与 Android 架构组件一起使用
【发布时间】：2018-11-17 19:32:30
【问题描述】：

我在 Android 开发方面已经错过了大约一年的时间，男孩，需要咀嚼的内容有多大：Kotlin、LifeCycle、Room、ViewModel、Dagger 等等。

我正在努力了解新的 MVVM 推荐模式，虽然看到一些更“标准化”的东西真的很棒，但有些事情还不清楚。

为了让事情变得简单，让我们有一个简短的示例。

首先，创建实体

@Entity(tableName = "user_table")
public class User {

   @PrimaryKey
   @NonNull
   @ColumnInfo(name = "name")
   //vars, getters, setters
}

然后创建 DAO

@Dao
public interface UserDao {

   @Insert
   void insert(User user);
...
}

然后，我需要创建存储库。这基本上是我的问题开始的地方。

我在官方文档中也看到了很多使用 Dagger2 的示例。虽然我仍然在与 Dagger 斗争以正确理解依赖注入，但我的问题是，为什么我需要使用 Dagger？我确实了解解耦组件可以更轻松地进行测试，但这是否一定适用于小型项目？为什么不直接在 ViewModel、Repository、DAO 之间进行交互而不进行注入（也许在构造函数上传递了类）？

附带说明一下，从 Kotlin 开始可能是一个好点。虽然我觉得它很酷，但我看到官方文档/指南的许多部分仍然只有 Java 示例......所以我有点想用旧 Java 学习新东西，但同时，因为我以前的项目是在javascript，切换到 kotlin 不会那么难...

【问题讨论】：

依赖注入总是有用的，如果你有一个依赖于一个依赖的依赖。

标签： android mvvm kotlin dagger-2

【解决方案1】：

依赖注入有很多好处。正如您已经指出的那样，它促进了解耦和可测试性。但 Dagger 真正吸引人的是依赖管理的易用性。 Dagger 在编译时计算出你的依赖图，甚至提供本地化（或全球化）生命周期和范围的机制。它也是基于组件的，因此可以轻松构建。

在小型项目中使用匕首是有争议的。如果您的项目包含简单的依赖关系图并且不是不断发展的，那么来自 dagger 的添加代码（和足迹）可能有点过多（如果您还不熟悉，更不用说学习曲线了）。

但在我看来，使用依赖注入总是一件好事。它提倡 SOLID 原则和更简洁的架构。

【讨论】：