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

我们是否需要为域中的每个方法创建UseCases接口？Android Clean Architecture UseCase用于存储库的每种方法？

例如，假设我有这样的仓库接口

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

正如你可以看到有size()方法，在数据库或文件返回的记录数，等等。而且这种方法非常快。我想这个方法不需要UseCase，因为它不会阻塞UI线程并且可以同步执行。

所以，你可以解释我，当你创建UseCase和当你不这样做。基本上有UseCase创建任何规则？

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

在此先感谢;）

而且我开了Android的CleanArchitecture回购相同issue在GitHub上，但没有人回答了这个问题还没有，这就是为什么我问这里。

来源

2017-04-03 Mike Herasimov

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

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

@drhr“域与数据之间的1对1映射会破坏将它们分开的目的”我知道，在这种情况下，我猜MVP的用法更好，但是对于我的情况，您可以提出什么建议？ –

有趣的问题！

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

注意我说程序员？只有当你去工作，坐下时，老板才会给你一个规范，然后你编码8小时，然后回家。但是，通常情况并非如此，我们中的一些人也是建筑师。（这是我下面点过于简单化了。）

从你的原职的情况下，为什么大家在评论中你跳是因为这个...

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

简而言之：在测试驱动的开发中，在编写一个失败的测试之前，您不要编写单个字符的代码。用例驱动开发同样如此;除非你有一个你正在试图解决的用例，否则你不会编写单一的代码。

和

正如你可以看到有大小（）方法，在>数据库或文件返回的记录数，等等。而且这种方法非常快。我猜想>这个方法不需要UseCase，因为它不会阻塞UI>线程并且可以同步执行。

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

因此，所有这样说，让我们再回到size()功能在你的ThingRepository，唯一的原因，你应该添加了size()功能是解决使用案例

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

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

如果你想首先要解决size()使用情况，您的看板可能是乱序，如“显示的东西用户”是Presenter功能和实现细节应推迟到最后一个负责时刻。

那么，size()函数是否真的需要在那里呢？除非你有充分的理由把它放在那里，而不是直到你需要它。

来源

2017-09-30 13:31:19

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

回答

相关问题