【问题标题】:Pass too much params from UI to UseCase Android Clean Architecture从 UI 向 UseCase Android Clean Architecture 传递太多参数
【发布时间】:2021-03-15 11:25:28
【问题描述】:

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

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

  1. data:我创建了一个JobRequest,如下所示:
data class JobRequest(
    @Expose @SerializedName("p1") val p1: String?,
...
    @Expose @SerializedName("p7") val p7: String?
)
  1. 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()
}
  1. 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 函数所需的内容。我错了吗?

【问题讨论】:

    标签: android design-patterns use-case clean-architecture


    【解决方案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 函数。不要担心正确的方法。满足你自己的需要。
    猜你喜欢
    • 2017-08-28
    • 1970-01-01
    • 2021-04-02
    • 2015-10-10
    • 1970-01-01
    • 2016-04-24
    • 1970-01-01
    • 1970-01-01
    • 1970-01-01
    相关资源
    最近更新 更多