Чистая архитектура - должна ли простая логика просмотра быть в Presenter или в View?

У меня есть простой пример:

Пользователь выбирает дату в календаре, затем эта дата указывается в метке. Если дата не указана или выбрана недопустимая дата, вместо нее должен быть помещен заполнитель.

Мой вопрос: какой из этих подходов лучше подходит для чистой архитектуры?

1) Отправьте объект Date из Presenter -> View, объект может быть нулевым. Просмотр решает, является ли дата нулевой, чтобы заполнить текст, а если нет, форматировать его.
Просмотр полностью определяет способ отображения интерфейса на основе полученной даты

2) Presenter отправляет отформатированную строку даты в View, но если она пуста, View устанавливает заполнитель. Presenter определяет формат значения, поскольку это бизнес-правило, но View решает, как данные отображаются графически, поэтому View определяет текст-заполнитель и компоненты, которые будут изменены. Предположим, что интерфейс может измениться на f.e. заполнитель помещается в другую метку, а поле даты остается пустым

3) Presenter дает команду View как установить текст даты, так и установить текст-заполнитель (известный только View, поскольку это статический текст). View получает информацию о том, что делать. Presenter точно знает, какие компоненты есть у View, и контролирует их. Но статические тексты являются компонентом интерфейса, поэтому Views решает, какой текст-заполнитель установить.

4) Presenter полностью определяет, что будет отображаться в пользовательском интерфейсе, View - это просто слой для подключения к компонентам пользовательского интерфейса, Presenter знает точно или в основном, как отображается View

Для меня Presenter должен управлять только общими событиями ввода и вывода из View, оставляя всю ответственность за View за то, как элементы рисуются, какие форматы используются и даже как извлекаются входные данные, так что если пользовательский интерфейс изменяется, ввод-вывод основного экрана используется кейсы останутся действительными в Presenter.

Однако я видел примеры кода, которые дают гораздо больший контроль докладчику, а пользовательский интерфейс - это просто каркасный способ рисования элементов и захвата пользовательского ввода.


android clean-architecture architecture viper mvp
person htafoya    schedule 05.08.2019    source источник

Ответы (1)


arrow_upward
3
arrow_downward

Вы можете привести доводы в пользу любого из этих 4-х, чего вы действительно хотите, так это согласованности всей кодовой базы после того, как вы ее выбрали.

Лично я бы выбрал # 3, он дает наибольший контроль ведущему, не допускает условной логики в представлении и, как вы сказали, больше всего отделяет пользовательский интерфейс от докладчика, позволяя менять местами пользовательский интерфейс и не менять ведущий.

то есть два метода

Presenter.showDateSelected(long dateTimeSelectedInMillis)

Presenter.showDateSelectedIsInvalid()

никогда не передавайте null, когда вы действительно знаете, что означает null (недопустимая дата), поскольку вы подразумеваете, что всегда хотите быть явным.

Выше я решил передать примитив, но передача объекта Date также может быть аргументирована, это просто связывает вас с платформой, или, возможно, вы могли бы создать свой собственный объект View Domain Date Date, снова у вас есть несколько вариантов того, как Presenter взаимодействует с Вид.

Все вышеперечисленные варианты являются разновидностью CleanArchitecture, и что делает ее наиболее чистой - это последовательность и ясность в выборе решений.

person Blundell    schedule 05.08.2019