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

Posted 2023-02-15

【中文标题】每种存储库方法的Android Clean Architecture UseCase？

【英文标题】：Android Clean Architecture UseCase for each method of repository?

【发布时间】：2017-08-28 18:05:31

【问题描述】：

我们是否需要从领域层的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，但还没有人回答，这就是我在这里问的原因。

【问题讨论】：

UseCases 用于表示高级域逻辑，例如“获取用户列表”。获取用户列表可以从网络、本地存储库或其他方法中提取内容。您不希望它是与存储库的一对一映射，因为存储库位于架构中的不同层上。域和数据之间的一对一映射会破坏分离它们的目的。

@drhr 所以在我的情况下你建议我不要创建 UseCase？

@drhr “域和数据之间的一对一映射会破坏分离它们的目的”我明白了，我想在这种情况下使用 MVP 更好，但你有什么建议我的情况？

我的意思是，您不一定要严格从较低的抽象级别构建您的用例。在很多情况下，UseCase 只需要使用一个较低级别的函数——没关系。但是您不应该觉得您需要更高级别的逻辑来表示每个较低级别的逻辑。请注意 README 中域和数据层是如何分开的。一个用例最终可能会将它们中的许多组合在一起，这是它们真正实现其目的的地方。在这里自上而下而不是自下而上可能会有所帮助。

【参考方案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() 函数真的需要在那里吗？除非你有充分的理由把它放在那里，除非你需要它。

【讨论】：

我希望你能更专注于回答一般问题，而不是尺寸细节。答案开始很好，但可以扩展很多

4 年前，我进入职业生涯大约 1 年，但经验并不丰富，哈哈。我同意这可以扩展到更普通的读者，但我会重写我读过的书，它给了我驱动答案的想法。所以我的扩展答案很简单；查看几本书：清洁架构 - 罗伯特 C 马丁。领域驱动设计 - Eric Evans

我正在阅读它，因为我们评论啊哈