从 UI 向 UseCase Android Clean Architecture 传递太多参数

Posted 2023-03-31

【中文标题】从 UI 向 UseCase Android Clean Architecture 传递太多参数

【英文标题】：Pass too much params from UI to UseCase Android Clean Architecture

【发布时间】：2021-03-15 11:25:28

【问题描述】：

我正在申请 Clean Architecture，但实际上还有很多问题。

假设，我的 API @POST fun createJob(@Body request: JobRequest)。并且参数是从 UI 提供的。所以，

在data：我创建了一个JobRequest，如下所示：

data class JobRequest(
    @Expose @SerializedName("p1") val p1: String?,
...
    @Expose @SerializedName("p7") val p7: String?
)

在domain: 我创建了一个CreateJobUseCase，如下所示：

class CreateJobUseCase(private val userRepository: UserRepository) :
    BaseUseCase<CreateJobUseCase.Input, Job>() 

    override suspend fun execute(input: Input): Job 
        return userRepository.createJob(input.p1, ...input.p7)
    

    data class Input(
       val p1: String,
       ....
       val p7: String,
   ) : BaseInput()

在presentation：我会从ViewModel 打电话，比如：

   createJobUseCase.execute(CreateJobUseCase.Input(p1, p2...p7)) 
     //handle output
   

我的问题是：

在domain，我的UserRepository接口应该像A还是B？

A: suspend fun createJob(input: CreateJobUseCase.Input) : Job

or

B: suspend fun createJob(p1: String,... p7: String) : Job

在很多项目中，我看到他们使用B，似乎repository功能被清除了。但是，我认为A 仍然可以，因为它仍然遵循依赖规则，并且CreateJobUseCase.Input 已经包含了createJob 函数所需的内容。我错了吗？

【参考方案1】：

这取决于您要在函数中放入什么逻辑。 总的来说，我认为你应该选择你更喜欢和更适合你需求的任何变体。

另外，如果您要使用相同类型的变量，我可以提出另一个选项C)。也许 vararg 会更好地满足您的需求？至少函数的构造函数会更短更简洁。例如：

suspend fun createJob(vararg p: String) 
    for (item in p) 
        println(item)
    

然后你可以这样调用你的函数：

createJob("1", "2", "3")

【讨论】：

感谢您的回答，您给出的 C 是我的特殊情况。我想听听更多关于正确方法的解释，因为我不确定我的解决方案。

例如，如果您打算用单元测试覆盖这个用例，您应该考虑如何将数据传递给createJob 函数。您会如何发现它对您更方便...假设您将进行 5 种不同的测试。将 A CreateJobUseCase.Input 传递给 createJob 函数是否更方便，或者将 B p1: String,... p7: String 传递给 createJob 函数会更方便，还是将 C vararg p: String 传递更方便到createJob 函数。不要担心正确的方法。满足你自己的需要。