Здравствуйте!

Стараюсь написать программу с "хорошей" архитектурой.
Читал про Чистую архитектуру:
https://habr.com/ru/articles/499078/

Как я понял, в соответствии с Чистой архитектурой, выходные данные ResponseModel бизнес-операции (UseCase Interactor) после ее завершения "возвращаются" в вызывающий слой через интерфейс OutputPort.
Интерфейс OutputPort реализуется в вызывающем слое как объект Presenter.
Но ведь OutputPort "возвращается" только при завершении бизнес-операции, через OutputPort возвращаются результаты выполнения.

А как сделать, чтобы происходило изменение пользовательского интерфейса именно в процессе выполнения длительной бизнес-операции?

Например.
Бизнес-операция — это обработка вложенных файлов и папок. Обработка каждой папки достаточно длительная.
Нужно, чтобы при выполнении этой операции в окне отображалась таблица с колонками.
При начале обработки новой папки\подпапки в таблице должна появляться новая строка и в первой колонке "Имя папки" таблицы отображается имя папки.
По ходу обработки папки (при обработке очередного файла в этой папки) во второй колоке "Файл" должна появиться строка "обрабатывается файл ххххх". После обработки всех файлов в колонке таблицы "Результат" должен появиться результат обработки папки.

В общем-то по смыслу ничего сложного.
Но как это реализовать, придерживаясь принципов Clean Architecture?
Как вызывающий слой должен вызвать UseCaseInteractor?
Что должна сделать процедура бизнес-операции, чтобы "сработали" все эти OutputPort, Presenter и т.д., и чтобы в итоге пользователь видел процесс заполнения таблицы?

Объясните, пожалуйста.
Если можно — покажите какой-нибудь подходящий пример кода.

Здравствуйте, zelenprog, Вы писали:

Z>Читал про Чистую архитектуру:
Z>https://habr.com/ru/articles/499078/

Z>Объясните, пожалуйста.
Z>Если можно — покажите какой-нибудь подходящий пример кода.

Ну я бы задал вопрос там, где можно найти апологетов того подхода, который вы пытаетесь использовать.
Так что, имхо, наиболее продуктивно — задавать вопросы под статьей, на которую вы привели ссылку.

МР>Ну я бы задал вопрос там, где можно найти апологетов того подхода, который вы пытаетесь использовать.
МР>Так что, имхо, наиболее продуктивно — задавать вопросы под статьей, на которую вы привели ссылку.

В этом подходе нету ничего особенного. Я думаю, что любой программист в том или ином виде применяет этот подход.
Этот подход — это просто описание принципа SRP, который необходимо использовать в любой программе, применительно к архитектуре ПО.
Просто автор "Чистой архитектуры" дал своеобразные названия классам: Controller, Presenter, InputPort, OutputPort, UseCaseInteractor.

Вопрос у меня возник как применить всё это к длительной операции.

Здравствуйте, zelenprog, Вы писали:
Z>Вопрос у меня возник как применить всё это к длительной операции.

Длительную операцию надо разбить на отдельные составляющие.

Например, пользователь запускает вычисление где-то на сервере.
Это первая субоперация. Возврат ее — вычисления успешно начаты или ошибка (например, входные параметры неправильные).

Далее по логике UI можно опрашивать статус вычислений (например, по таймеру).
Эта субоперация вернет прогресс, признак завершения или ошибку.

И плюс еще можно добавить субоперацию отмены вычислений.

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

Здравствуйте, qaz77, Вы писали:

Q>Здравствуйте, zelenprog, Вы писали:
Z>>Вопрос у меня возник как применить всё это к длительной операции.

Q>Длительную операцию надо разбить на отдельные составляющие.

Q>Например, пользователь запускает вычисление где-то на сервере.

И получает Id начатой операции.

Q>Это первая субоперация. Возврат ее — вычисления успешно начаты или ошибка (например, входные параметры неправильные).

Q>Далее по логике UI можно опрашивать статус вычислений (например, по таймеру).

Q>Эта субоперация вернет прогресс, признак завершения или ошибку.

Q>И плюс еще можно добавить субоперацию отмены вычислений.

Q>Если взаимодействие UI с остальной системой носит не односторонний характер (клиент-сервер),
Q>то можно организовать подписки на различные события. Компоненты UI смогут регистрировать себя в качестве слушателей на то, что для них требуется.

Z>Стараюсь написать программу с "хорошей" архитектурой.
На моей памяти уж года 3 как стараешься. А мог бы просто за это время набить шишек, поняв где и как стоит делать, а где – нет, плюс заодно прокачаться, поднять свой скилл и уже чуть ли не интуитивно понимать, где как стоит и не стоит делать. А ты вместо этого надрач ищешь идеальный рецепт "хорошей" программы.

Сорян, что поломаю розовые очки: такого рецепта нет никакого "правильного" варианта написания архитектуры. Везде будут изъяны, недочеты и где-то что-то впоследствии захочется переделать.

Welcome to the real world!

Ну или да, можно всю жизнь тренироваться на кошечках, писать хеллоу ворлды в вакууме и натягивать сов на глобусы разных цветов размеров.

PS простите, наболело от однообразия твоих постов.
PS2 не ошибаясь и не пробуя, а зарываясь лишь в теорию ты из zelenprog-ера в seniorprog-ера не превратишься

Здравствуйте, zelenprog, Вы писали:

Z>Здравствуйте!

Z>Стараюсь написать программу с "хорошей" архитектурой.
Z>Читал про Чистую архитектуру:
Z>https://habr.com/ru/articles/499078/

Z>Как я понял, в соответствии с Чистой архитектурой, выходные данные ResponseModel бизнес-операции (UseCase Interactor) после ее завершения "возвращаются" в вызывающий слой через интерфейс OutputPort.
Z>Интерфейс OutputPort реализуется в вызывающем слое как объект Presenter.
Z>Но ведь OutputPort "возвращается" только при завершении бизнес-операции, через OutputPort возвращаются результаты выполнения.

Z>А как сделать, чтобы происходило изменение пользовательского интерфейса именно в процессе выполнения длительной бизнес-операции?

Z>Например.
Z>Бизнес-операция — это обработка вложенных файлов и папок. Обработка каждой папки достаточно длительная.
Z>Нужно, чтобы при выполнении этой операции в окне отображалась таблица с колонками.
Z>При начале обработки новой папки\подпапки в таблице должна появляться новая строка и в первой колонке "Имя папки" таблицы отображается имя папки.
Z>По ходу обработки папки (при обработке очередного файла в этой папки) во второй колоке "Файл" должна появиться строка "обрабатывается файл ххххх". После обработки всех файлов в колонке таблицы "Результат" должен появиться результат обработки папки.

Z>В общем-то по смыслу ничего сложного.
Z>Но как это реализовать, придерживаясь принципов Clean Architecture?
Z>Как вызывающий слой должен вызвать UseCaseInteractor?
Z>Что должна сделать процедура бизнес-операции, чтобы "сработали" все эти OutputPort, Presenter и т.д., и чтобы в итоге пользователь видел процесс заполнения таблицы?

Z>Объясните, пожалуйста.
Z>Если можно — покажите какой-нибудь подходящий пример кода.

Почитал бы книжку: Чистая архитектура она того стоит и кстати, там есть про то, что перебарщивать в архитектуре не стоит без явной в этом необходимости.

Q>Почитал бы книжку: Чистая архитектура она того стоит и кстати, там есть про то, что перебарщивать в архитектуре не стоит без явной в этом необходимости.

Я ее как раз сейчас читаю.
Только в книжке там все просто и простые примеры. Но вот что касается длительных операций там нифига не описано.

DP>... А мог бы просто за это время набить шишек ...
Так вот я и набиваю шишки.

DP>... можно всю жизнь тренироваться на кошечках, писать хеллоу ворлды в вакууме и натягивать сов на глобусы разных цветов размеров.
Я пишу реальное приложение, используемое на практике
Да, это приложение небольшое.

DP>... Сорян ... простите ...
Все нормально.
Я даже приветсвую критику.

DP>... наболело от однообразия твоих постов
Да, все посты касаются архитектуры.
Но в каждом посте затрагиваются разные конкретные моменты, которые в явном виде нигде не описаны.

DP>... нет никакого "правильного" варианта написания архитектуры ....
Ну как же нет?
Ведь "шаблоны", "принципы" — это и есть некие "правила" "правильной" архиектуры, которые были сформулированы в теоретическом виде только на основе анализа многих реальных программ.
Нарушая эти принципы, в итоге с очень большой вероятностью получится нерабочая\неподдерживаемая программа.

Здравствуйте, zelenprog, Вы писали:


Q>>Почитал бы книжку: Чистая архитектура она того стоит и кстати, там есть про то, что перебарщивать в архитектуре не стоит без явной в этом необходимости.

Z>Я ее как раз сейчас читаю.
Z>Только в книжке там все просто и простые примеры. Но вот что касается длительных операций там нифига не описано.

На самом деле вся архитектура сводится к одной мысли: есть код который решает проблему, а есть код который позволяет этот код использовать и представляет из себя в большей части случаев рутину. Проблема в собственно в том, что у многих усилия при разработке почему-то сосредоточены на втором и все проблемы возникают там же, а не на первом. В твоем случае главный код это тот код, который представляет долго выполняющиеся задачу, а как он будет взаимодействовать с UI — это уже второстепенно.

Q>Длительную операцию надо разбить на отдельные составляющие.

Q>Например, пользователь запускает вычисление где-то на сервере.
Q>Это первая субоперация. Возврат ее — вычисления успешно начаты или ошибка (например, входные параметры неправильные).
Qulac>И получает Id начатой операции.

ОК, понятно.

Q>Далее по логике UI можно опрашивать статус вычислений (например, по таймеру).

А если нету таймера? Если все выполняется в одном потоке?
То есть: по событию формы вызывается контроллер, контроллер создает презентера и вызывает бизнес-операцию... И все это один поток.
Как в этом случае "опрашивать" статус вычислений?
Я то думал, что согласно "чистой архитектуре", бизнес-операция через интерфейс презентера должна сама сообщать о статусе.

Q>Длительную операцию надо разбить на отдельные составляющие.
Q>Далее по логике UI можно опрашивать статус вычислений (например, по таймеру).
Q>Эта субоперация вернет прогресс, признак завершения или ошибку.

Сразу возник еще вопрос.
По условвиям задачи, UI должен выполненные действия бизнес-операции отобразить в виде таблицы.
Если UI будет сам опрашивать состояние, то при очередном опросе UI должен получить список выполненных действий, которые были выполнены с момента предыдущего опроса.
Как это сделать?

Здравствуйте, zelenprog, Вы писали:

Z>А если нету таймера? Если все выполняется в одном потоке?

Есть системное время, вычисляй разность с последней операции и если оно больше заданной дельты обновляй интерфейс взаимодействия с пользователем.

Вопрос здесь скорее во сколько тебе обходится показ прогресса и стоит ли выводить его весь с каждой операции или только часть с задержкой по дельте времени, например, 0.1 сек, чтобы показать, что он есть.

И в принципе я написал по этому поводу.
Почему программисты прошлого были умнее

Это типичная ловушка абстракций. GUI это самый обычный условно бесконечный цикл пока не будет выполнено условие выхода. И внутри него крутятся циклы обработки сообщений или называй как хочешь.

Фактически это машина состояний как в том же контроллере. То есть вся эта байда будет работать даже если программист не продвинулся дальше процедурного программирования с блоком, ветвлением и циклом.

Плюс получение системного времени или чего-то похожего учитывающего перевод часов. В общем смысл в простеньких алгоритмах уровня программистов аппаратчиков, см. статью выше.

А вот на третьем уровне абстракционистов нет понимания работы компьютера. На нём работают уже состоявшиеся в алгоритмах программисты, которые просто записывают их иначе.

Это как раз все эти шаблоны проектирования и прочее. Например, шаблон проектирования итератор внутри является самым обычным циклом относящимся к синтаксису языка программирования.

Все эти шаблоны это здорово и хорошо, но они не дают понимания алгоритмов, причём даже самых простых, а часто напротив превращают нечто сверх простое в сверх сложное.

Я писал ради опыта реализацию со временем сам, так и видел её на стековерфлоу. Если лень писать самому просто найди поиском готовое решение.

А про Мартина Роберта с его книгами Чистым Кодом, Чистым Кодером, Чистой Архитектурой и Чистым Agile, скажу так, сам он начинал с перфокарт. Статья же на хабре вторична и не имеет отношения к этому автору.

Между прочим UML это тоже попытка абстрагироваться, но уже от языков программирования. А в итоге получаем ещё один язык программирования с рамочками.

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

Четвёртому поколению пользователей ещё сложнее, так как они сидят на чужих готовых библиотеках алгоритмов в виде чёрных ящиков. И даже если код открыть за многоэтажными абстракциями сложно найти алгоритмы.

Кстати, интересная мысль вроде бы от Мартина Роберта, парадигмы всегда ограничивают возможности, а не добавляют их. Но если продолжить мысль, то став пользователем или пусть даже абстракционистом тоже ограничиваешь собственные возможности.

Здравствуйте, zelenprog, Вы писали:

Z>По условвиям задачи, UI должен выполненные действия бизнес-операции отобразить в виде таблицы.
Z>Если UI будет сам опрашивать состояние, то при очередном опросе UI должен получить список выполненных действий, которые были выполнены с момента предыдущего опроса.
Z>Как это сделать?

В этом случае прогресс это не % выполнения, а список сделанного.
В простейшем случае — лог, список строк. Или что-то более сложное, в зависимости от задачи.

Здравствуйте, zelenprog, Вы писали:

Z>А если нету таймера? Если все выполняется в одном потоке?

Если писали на Win API или чем-то подобном, то должны понимать, что однопоточность и таймер — не взаимоисключающие вещи.

Z>То есть: по событию формы вызывается контроллер, контроллер создает презентера и вызывает бизнес-операцию... И все это один поток.
Z>Как в этом случае "опрашивать" статус вычислений?
Z>Я то думал, что согласно "чистой архитектуре", бизнес-операция через интерфейс презентера должна сама сообщать о статусе.

Вообще плохой подход.
UI и вычисления в одном потоке — это уровень программ 25 лет назад.
Если деваться некуда, то да, тот или иной вид callback. Вычислительное ядро дергает какой-то интерфейс (слушатель, прогресс, ...) и надо обеспечивать обновление (перерисовку) UI. Весь такой треш с while (PeekMessage(...)), т.к. мы в единственном потоке и не в цикле обработки сообщений, а в стеке вычислительной задачи.

Z>>А если нету таймера? Если все выполняется в одном потоке?

Q>Если писали на Win API или чем-то подобном, то должны понимать, что однопоточность и таймер — не взаимоисключающие вещи.

Да, писал, правда очень давно.
Я понимаю, что есть основной цикл приложения, обрабатывающий события от операционки.
Плюс есть обработчики прерываний.

Z>>То есть: по событию формы вызывается контроллер, контроллер создает презентера и вызывает бизнес-операцию... И все это один поток.
Z>>Как в этом случае "опрашивать" статус вычислений?
Z>>Я то думал, что согласно "чистой архитектуре", бизнес-операция через интерфейс презентера должна сама сообщать о статусе.

Q>Вообще плохой подход.
Q>UI и вычисления в одном потоке — это уровень программ 25 лет назад.
Q>Если деваться некуда, то да, тот или иной вид callback. Вычислительное ядро дергает какой-то интерфейс (слушатель, прогресс, ...) и надо обеспечивать обновление (перерисовку) UI. Весь такой треш с while (PeekMessage(...)), т.к. мы в единственном потоке и не в цикле обработки сообщений, а в стеке вычислительной задачи.

Да именно так. "Моя" среда разработки предоставляет только такой механизм.
Само приложение конечно же работает в цикле. Но мне как разрабочику управление этим циклом не доступно.
Мне доступны только методы-события от элементов управления и какие-то немногочисленные обработчики внешних событий, срабатывающие в момент ожидания ввода от пользователя.

Только не понял, что вы имеете ввиду про "треш с while (PeekMessage(...))"?
Где должен быть организован этот while? В бизнес-логике?

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

То есть, как мне кажется, в программе должно быть два механизма взаимодействия с UI:
— первый: через опрос состояния бизнес-логики
— второй: через непосредственный вызов методов-реализаций перерисовки UI через интерфейсы, вызываемые из бизнес-логики.
Второй механизм покрывает возможности первого, и делает первый механизм ненужным.
И, как я понимаю, Clean Architecture описывает именно второй способ.

Z>>А если нету таймера? Если все выполняется в одном потоке?

V>Есть системное время, вычисляй разность с последней операции и если оно больше заданной дельты обновляй интерфейс взаимодействия с пользователем.
V>Вопрос здесь скорее во сколько тебе обходится показ прогресса и стоит ли выводить его весь с каждой операции или только часть с задержкой по дельте времени, например, 0.1 сек, чтобы показать, что он есть.

Все правильно.
Какой код (какой слой\модуль\метод) дожен выполнять эту работу? И откуда будет вызываться этот код?
То есть у меня вопрос скорее про разделение отвественности, а не про "техническую" начинку.

V>И в принципе я написал по этому поводу.
V>Почему программисты прошлого были умнее

Да, я читал эту статью. И горячие обсуждения этой статьи.

V>Это типичная ловушка абстракций. GUI это самый обычный условно бесконечный цикл пока не будет выполнено условие выхода. И внутри него крутятся циклы обработки сообщений или называй как хочешь.
V>Фактически это машина состояний как в том же контроллере. То есть вся эта байда будет работать даже если программист не продвинулся дальше процедурного программирования с блоком, ветвлением и циклом.
V>Плюс получение системного времени или чего-то похожего учитывающего перевод часов. В общем смысл в простеньких алгоритмах уровня программистов аппаратчиков, см. статью выше.
V>А вот на третьем уровне абстракционистов нет понимания работы компьютера. На нём работают уже состоявшиеся в алгоритмах программисты, которые просто записывают их иначе.
V>Это как раз все эти шаблоны проектирования и прочее. Например, шаблон проектирования итератор внутри является самым обычным циклом относящимся к синтаксису языка программирования.
V>Все эти шаблоны это здорово и хорошо, но они не дают понимания алгоритмов, причём даже самых простых, а часто напротив превращают нечто сверх простое в сверх сложное.

В общем согласен. Знание и понимание "азов" помогает в более высокоуровневом программировании.
Я начинал писать на ассемблере, потом на С, потом на С++ и так далее.
Кстати и эту программу я пишу на процедурном языке, в котором нету классов.
Но это не исключает применение принципов разделения кода, которые были наработаны "потом и кровью".
Эти принципы были наработаны в том числе и программистами прошлого, которые дали нам (современным программистам) огромный опыт, в том числе и такой опыт как не надо делать.
Ведь, например, насколько я помню MVC был придуман когда еще не было ни ООП ни шаблонов проектирования.

V>В общем сначала нужно учить алгоритмы и структуры данных, пусть даже это будет процедурное программирование, и лишь потом переводить работающий алгоритм в некую абстракцию по сути делающую тоже самое.

Алгоритм тут как раз простой: изменили данные — перерисуй интерфейс. Структуры данных тоже понятные и простые.
Тут вопрос больше относится к тому, как организовать\разделить код так, чтобы программа оставалась поддерживаемой\расширяемой и т.д.
Чистая Архитектура — мне кажется именно про это.
Автор предлагает разделить этот код на части (грубо говоря на отдельные методы), которые он называет определенными терминами, и которые должны вызываться в следующем порядке:
Controller -> UseCaseInteractor (InputPort) -> Presenter (OutputPort).

V>А про Мартина Роберта с его книгами Чистым Кодом, Чистым Кодером, Чистой Архитектурой и Чистым Agile, скажу так, сам он начинал с перфокарт. Статья же на хабре вторична и не имеет отношения к этому автору.

Да, я это понимаю. Книгу читаю.
Но в самой книге нету про длительные операции.
Там, например, говорится о подготовке отчета: Контроллер вызвал Интерактора, который готовит отчет. Интерактор после выполнения отдает эти данные Презентеру. Презентер управляет отображением этого отчета.
Но мне нужно, чтобы кроме отображения отчета, еще отобразить и процесс его формирования\подготовки. Об этом в книге ничего не сказано.
Вот поэтому я и советуюсь с сообществом: как это лучше сделать?

Здравствуйте, zelenprog, Вы писали:

Z>Только не понял, что вы имеете ввиду про "треш с while (PeekMessage(...))"?
Z>Где должен быть организован этот while? В бизнес-логике?

В обработчике изменения прогресса, т.е. в callback, который дергает бизнес-логика.
Если не прокачать скопившиеся в очереди сообщения, то UI нормально не перерисуется.

Z>>По условвиям задачи, UI должен выполненные действия бизнес-операции отобразить в виде таблицы.
Z>>Если UI будет сам опрашивать состояние, то при очередном опросе UI должен получить список выполненных действий, которые были выполнены с момента предыдущего опроса.
Z>>Как это сделать?

Q>В этом случае прогресс это не % выполнения, а список сделанного.
Q>В простейшем случае — лог, список строк. Или что-то более сложное, в зависимости от задачи.

Какой код должен сформировать это список сделанного?
Как мне кажется, интерфейс (то есть Presenter по терминологии Чистой Архитектуры) не должен этого делать, он должен только управлять отображением полученных данных.
Бизнес-логика (UseCaseInteractor) по идее тоже не дожлна делать этот список, так как она только выполняет свою работу и фиксирует информацию о ходе своего выполнения.

Значит, дожен быть еще какой-то код, который:
1) при появлении новой информации о ходе выполнения отслеживает "разницу" по сравнению с прошлым состоянием, и делает список выполненных действий.
2) каким-то образом оповещает UI и передает в UI этот список.

В каком месте\слое Чистой Архитектуры должен находиться этот код?
Из прочтения книги это неясно.

Q>На самом деле вся архитектура сводится к одной мысли: есть код который решает проблему, а есть код который позволяет этот код использовать и представляет из себя в большей части случаев рутину. Проблема в собственно в том, что у многих усилия при разработке почему-то сосредоточены на втором и все проблемы возникают там же, а не на первом. В твоем случае главный код это тот код, который представляет долго выполняющиеся задачу, а как он будет взаимодействовать с UI — это уже второстепенно.

Абсолютно согласен.
Главный код у меня — это код, который обрабатывает данные. Он уже работает и все что надо выполняет.
Теперь вот и встал вопрос про "второстепенную" задачу — отобразить ход выполнения.

Несмотря на то, что она второстепенная, нужно эту задачу решить грамотно.
Сейчас информация о ходе выполнения должна отображаться в табличке в десктопном UI. Потом потребуется чтобы все это отображалось при запуске из консоли, потом по веб-запросу.
И, прочитав книжку, я не смог придумать как то сделать.
Поэтому прошу совета\помощи — придумать решение хотя бы в общих чертах.