为什么 ViewModel 的对象不应该直接操作数据库？

Question

我正在学习Android架构组件。

例如，为了更容易理解，如果我想构建一个 TO DO LIST 应用程序，我的项目创建 DAO 应该是

@Dao
public interface ItemDao {
    @Insert
    long insertItem(Item item);
}

我的 viewModel 可以使用这个 DAO 在我的 TODO 列表中插入一个项目。但是，在 架构组件 中，建议不要通过视图模型而是通过存储库来操作数据库。

所以，代码应该是这样的

public class ItemDataRepository {

    private final ItemDao itemDao;

    public ItemDataRepository(ItemDao itemDao) { this.itemDao = itemDao; }

    // --- CREATE ---

    public void createItem(Item item){ itemDao.insertItem(item); }

当我们不明白为什么时，这似乎是多余的。

我的问题是：为什么？

Answer 1

我使用 Repository 有几个原因：

关注点分离我让repo负责下载和存储所有数据。这样 ViewModel 就不必知道有关数据来源的任何细节，例如如果它来自 API 或缓存。它还使为 ViewModel 编写单元测试变得更容易，因为所有数据库和 API 逻辑应该已经在 Repository.
[= 的单元测试中进行了测试43=]
可重用性 假设您从 API 中获取数据并存储在数据库中。如果您将代码放在 ViewModel 中，然后想从应用程序的其他位置执行相同的操作，则需要复制粘贴代码。通过将其放在 Repository 中，您可以轻松共享实现。
共享数据 如果您有多个屏幕显示同一数据集的各个部分，在屏幕之间传递一个 Repository易于共享数据。不再试图在 Bundle 和 Intent.
Lifecycle 假设您从 API 下载数据以显示在您的视图中。如果您在 ViewModel 中获取数据，则必须在屏幕关闭并重新打开时重新下载它，因为 ViewModel 已被丢弃。但是，如果将其存储在 Repository 中，它可以使用 Application 生命周期，因此当您再次访问屏幕时，数据已经在缓存中。

为什么 ViewModel 的对象不应该直接操作数据库？

Why ViewModel's object shouldn't manipulate database directly?

android

dao

design-patterns

android-architecture-components