10

我们是否需要从领域层的接口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 上打开了同样的问题，但还没有人回答，这就是我在这里问的原因。

4

1 回答 1

5

有趣的问题！

简单的答案。作为程序员，您不编写用例。您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()功能真的需要存在吗？除非你有充分的理由把它放在那里，除非你需要它。

于 2017-09-30T13:31:19.623 回答