每种存储库方法的Android Clean Architecture UseCase？

Question

我们是否需要从领域层的Repository 接口为每个方法创建UseCases？

例如假设我有这样的 Repository 接口

interface ThingRepository {
    void create(Thing thing);
    void delete(Thing thing);
    List<Thing> readAll();
    int size();
}

如您所见，size() 方法返回数据库或文件中的记录数，无论如何。而且这种方法非常快。 我猜这个方法不需要UseCase，因为它不会阻塞UI线程并且可以同步执行。

那么你能解释我什么时候创建UseCases，什么时候不创建。基本上UseCase的创建有什么规则吗？

对不起，如果这个问题有一些误解。

提前致谢；）

我还在 github 上的 Android-CleanArchitecture repo 上打开了相同的 issue，但还没有人回答，这就是我在这里问的原因。

Answer 1

有趣的问题！

简单的答案。你作为一个程序员不要编写用例。您的specifications document 是您从中派生用例的地方。一旦你的用例在你的看板中排列得很好，那么你就开始解决这些问题。一次一个。

注意我说的是程序员？前提是你去上班，坐下来，老板给你一份规范，你编码 8 小时然后回家。然而，通常情况并非如此，我们中的一些人也是架构师。 （这对我的以下观点过于简单化了。）

从您原始帖子的上下文来看，为什么 cmets 中的每个人都在跳槽您是因为这个......

我们是否需要从领域层的 Repository 接口为每个方法创建 UseCases？

简单地说：在测试驱动的开发中，你不会写一个字符的代码，直到你先写一个失败的测试。用例驱动的开发也是如此。在您尝试解决用例之前，您不会编写单个字符的代码。

和

如您所见，有一个 size() 方法返回 >database 或文件中的记录数，无论如何。而且这种方法非常快。我猜想>这个方法不需要UseCase，因为它不会阻塞UI>线程并且可以同步执行。

听起来是这样的。 “我没有用例来显示数据库中的记录数，所以我在存储库接口中添加了一个size()函数，因为我认为它应该有一个，我正在尝试编写一个用例为了它。”这根本不是用例驱动开发的目标。

说了这么多，让我们回到ThingRepository 中的size() 函数。您应该添加size() 函数的唯一原因是解决一个用例。

示例：“应用程序应显示所有Things 的总数 数据库。

该用例的问题是，如果我向用户显示Things，那么我的Presenter 很可能注入了_ThingRepository。我宁愿运行_ThingRepository.readAll().Count()，因为它要么已经在内存中，要么需要在某个时间点用于其他Presenter 函数，这比再次访问数据库（可能在另一个国家）要快得多用于简单的记录计数。

如果您首先尝试解决size() 用例，您的看板可能出现故障，因为“向用户显示内容”是Presenter 函数和实现细节 应该推迟到最后一个负责任的时刻。

那么，size() 函数真的需要在那里吗？除非你有充分的理由把它放在那里，除非你需要它。