Чистая архитектура, оркестратор запросов данных, докладчик или сценарий использования/интерактора?

Кто должен организовывать/сопоставлять данные из пользовательского интерфейса? Например, войдите в систему, у меня есть username и password:

1.) должен ли я принять LoginParam как параметр моего докладчика, а затем в пользовательском интерфейсе создать объект 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))
      ...
   }
}

Если да, то почему? (Пожалуйста, обоснуйте свой ответ и укажите проблему, которая может возникнуть при неправильных решениях)

Из прочитанного я не нашел конкретного ответа на свой вопрос. (Или может я что-то пропустил/не понял, лол)


person Tenten Ponce    schedule 05.03.2018    source источник
comment
Пожалуйста, уточните, что смущает в моем вопросе, потому что я думаю, что урезал его, и он специфичен (по крайней мере, для меня). Не просто голосуйте против. Спасибо.   -  person Tenten Ponce    schedule 05.03.2018


Ответы (1)


В общем, дядя Боб говорит о «запросах, отправляемых из представления к контроллеру» и «моделях запросов, отправляемых от контроллера к интерактору». Контроллер должен будет преобразовать между запросом и моделью запроса.

В вашем случае вопрос будет заключаться в том, где вы создали LoginParam? Если класс принадлежит слою вариантов использования, ведущий должен его создать. Если он принадлежит слою интерфейсных адаптеров, представление создаст его.

Теоретически вы также можете решить передавать чистые строки из представления в контроллер и в интерактор варианта использования. Наличие пользовательского класса было бы проще расширять (изменение API без нарушения). Если у вас на самом деле более двух параметров, я бы выбрал конкретные объекты запроса (уровень адаптера интерфейса) и конкретные модели запросов (уровень варианта использования).

Более подробное обсуждение взаимодействия между контроллером, интерактором и презентатором вы можете найти в моем посте: https://plainionist.github.io/Implementing-Clean-Architecture-Controller-Presenter/

person plainionist    schedule 05.03.2018
comment
мой LoginParam из уровня пользователя/домена, поэтому, насколько я понимаю, поскольку это всего две строки (имя пользователя и пароль), это также удобно для просмотра, я должен передать его докладчику, тогда докладчик создаст LoginParam который удобен для варианта использования? - person Tenten Ponce; 06.03.2018
comment
Да. Это было бы прагматичным решением, которое подтверждается правилом зависимости. - person plainionist; 06.03.2018