干净的架构、数据请求编排器、演示器或 usecase/interactor？

Question

谁应该 orchestrate/map 来自 ui 的数据？比如登录，我有username和password：

1.) 我是否应该接受 LoginParam 作为我的演示者 的参数 然后从 UI 创建 LoginParam 那么供应对象呢？或者

public class LoginPresenter {

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

2.) 只需接受 username 和 password 然后 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.) 最后，将 username 和 password 从 presenter 传递到 usecase 然后 usecase 将创建 LoginParam API 调用的对象？

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))
      ...
   }
}

如果是，那为什么？（请证明你的答案，并指出错误的解决方案会出现的问题）

从我读过的内容来看，我没有找到任何具体的问题答案。（或者我 missed/didn 没听懂哈哈）

Answer 1

一般来说，Bob 叔叔谈论 "requests being sent from view to controller" 和 "request models sent from controller to the interactor"。控制器必须在请求和请求模型之间进行转换。

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

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

有关 controller-interactor-presenter 交互的更详细讨论，您可以在我的 post 中找到：https://plainionist.github.io/Implementing-Clean-Architecture-Controller-Presenter/

干净的架构、数据请求编排器、演示器或 usecase/interactor？

Clean Architecture, data request orchestrator, presenter or usecase/interactor?

java

android

clean-architecture