针对每个存储库方法的Android Clean Architecture UseCase？

Question

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

例如,假设我有这样的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上打开了同样的问题,但没有人回答它,这就是我在这里问的原因.

Answer 1

有趣的问题！

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

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

从您原始帖子的上下文来看，以及为什么评论中的每个人都跳到您身上的原因是...

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

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

和

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

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

因此，所有这一切是说，让我们再回到size()你的功能ThingRepository。您应该添加该size()函数的唯一原因是解决用例。

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

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

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

那么，这个size()功能真的需要存在吗？除非你有很好的理由把它放在那里，除非你需要它。