【问题标题】:Clean Architecture, data request orchestrator, presenter or usecase/interactor?清洁架构、数据请求协调器、演示者或用例/交互者?
【发布时间】:2018-03-05 15:14:20
【问题描述】:

谁应该从 ui 中编排/映射数据?比如登录,我有usernamepassword

1.) 我是否应该接受 LoginParam 作为 我的演示者的参数,然后从 UI 创建 LoginParam 对象然后提供它?或者

public class LoginPresenter {

   public void login(LoginParam loginParam) { //pass the parameter from ui
      loginUseCase.execute(loginParam)
      ....
   }
}

2.) 只接受usernamepassword 然后presenter 将创建LoginParam 以传递use case?或者

public class LoginPresenter {

   public void login(String username, String password) {
      //create the object in the presenter
      loginUseCase.execute(LoginParam.create(username, password)) 
   }
}

3.) 最后,将usernamepasswordpresenter 传递给usecase,然后usecase 将为API 调用创建LoginParam 对象?

public class LoginPresenter {
   public void login(String username, String password) {
      loginUseCase.execute(username, password) //pass it through
      ...
   }
}

然后是用例:

public class LoginUseCase {
   public Single<LoginResp> execute(String username, String password) {
      return userRepository.login(LoginParam.create(username, password))
      ...
   }
}

如果是,那为什么?(请说明你的答案,并指出错误解决方案会出现的问题)

从我所阅读的内容来看,我没有找到任何关于我的问题的具体答案。 (或者也许我错过了/不明白某些东西哈哈)

【问题讨论】:

  • 请澄清我的问题有什么令人困惑的地方,因为我认为我把它删减了并且它是具体的(至少对我来说)。不要只是投反对票。谢谢。

标签: java android clean-architecture


【解决方案1】:

一般来说,Bob 大叔谈到“请求从视图发送到控制器”和“请求模型从控制器发送到交互器”。控制器必须在请求和请求模型之间进行转换。

在您的情况下,问题是您在哪里创建了 LoginParam?如果该类属于用例层,演示者将创建它。如果它属于接口适配器层,则视图将创建它。

理论上,您还可以决定将纯字符串从视图传递到控制器和用例交互器。拥有一个自定义类会更容易扩展(非破坏性 api 更改)。如果您实际上有两个以上的参数,我会选择特定的请求对象(接口适配器层)和特定的请求模型(用例层)。

您可以在我的帖子中找到有关控制器-交互器-演示者交互的更详细讨论:https://plainionist.github.io/Implementing-Clean-Architecture-Controller-Presenter/

【讨论】:

  • my LoginParam 来自用户案例/域层,所以据我了解,因为它只有两个字符串(用户名和密码),而且查看起来很方便,我应该将其传递给演示者,然后演示者将创建LoginParam 方便用例吗?
  • 是的。这将是一个务实的解决方案,通过依赖规则确认。
猜你喜欢
  • 2016-08-16
  • 2017-10-03
  • 1970-01-01
  • 2014-12-15
  • 1970-01-01
  • 1970-01-01
  • 2016-11-30
  • 2018-02-05
  • 2019-12-20
相关资源
最近更新 更多