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

Question

Who should orchestrate/map the data from ui? For example, login, I have username and password:

1.) should I accept the LoginParam as parameter on my presenter then from UI, create the LoginParam object then supply it? Or

public class LoginPresenter {

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

2.) Just accepts the username and password then the presenter will create the LoginParam to be pass on use case? Or

public class LoginPresenter {

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

3.) Lastly, pass the username and password from presenter to usecase then the usecase will create the LoginParam object for API call?

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

then on use case:

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

If so, then why? (Please justify your answer, and point out the problem that will occur on the wrong solutions)

From the things that I've read, I didn't find any concrete answer to my question. (Or maybe I missed/didn't understand something lol)

Answer 1

In general Uncle Bob talks about "requests being sent from view to controller" and "request models sent from controller to the interactor". The controller would have to convert between request and request model.

In your case the question would be where have you created LoginParam? If the class belongs to the use case layer the presenter would create it. If it belongs to the interface adapters layer the view would create it.

Theoretically you could also decide to pass pure strings from view to controller and to the use case interactor. Having a custom class would be easier to extend (non-breaking api change). If you have actually more than two parameters I would go for specific request objects (interface adapter layer) and specific request models (use case layer).

A more detailed discussion about controller-interactor-presenter interaction you could find in my post: https://plainionist.github.io/Implementing-Clean-Architecture-Controller-Presenter/