Clean Architecture. Отображение в пользовательском интерфейсе процесса выполнения длительной бизнес-операции

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

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

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

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

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

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

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

0

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

Операция выполняется асинхронно. Одним из параметров является функция обратного вызова, которая вызывается после завершения каждого этапа обработки.

Это общий принцип. Конкретные детали зависят от того, что за UI у Вас. Например, возможно, у Вас будет опрос сервера в цикле (о текущем статусе операции).

0

Сообщение от Shamil1 Одним из параметров является функция обратного вызова, которая вызывается после завершения каждого этапа обработки. ... возможно, у Вас будет опрос сервера в цикле (о текущем статусе операции).

А что в данном случае будет OutputPort?
И как надо разделить эти действия между объектами Controller, Presenter?

Как я понимаю, моделью в этой программе будут данные о папках, файлах и результатах их обработки.
Верно?

0

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

Через переходник/адаптер. Псевдокод
Конечно используемые вызовы (SetProgress, UpdateProgress) непрозрачны для расчетов. Др словами расчет не никаких деталей UI. Индикатор может быть развесистое окно, но может и строка в консоли

0

Сообщение от Igor3D Через переходник/адаптер. Псевдокод...

Общая схема понятна.
А вот более конкретные моменты не понятно как надо делать.

Сообщение от Igor3D SetProgress(0, num_steps, ...)

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

И второй вопрос - мне все-таки хотелось бы это реализовать в рамках "Чистой архитектуры".
В вашем примере метод "void RenderFrame( void )" - это UseCase Interactor.
А где код, который выполняет роль InputPort и OutpputPort?

0

Сообщение от zelenprog Как я понимаю, моделью в этой программе будут данные о папках, файлах и результатах их обработки. Верно?

Да. Классы, специфичные для бизнес-логики, являются моделью.

Добавлено через 2 минуты

Сообщение от zelenprog не просто прогресс, а именно подробная информация о выполняемых действиях

Единственная разница, вместо числа (процент прогресса) будет объект (данные о прогрессе).

Добавлено через 4 минуты
Возможно, с учётом веб специфики будет проще реализовать функцию, которая выполняет операцию, на клиенте. На сервере будет выполняться отдельный шаг.

0

Сообщение от zelenprog И второй вопрос - мне все-таки хотелось бы это реализовать в рамках "Чистой архитектуры". В вашем примере метод "void RenderFrame( void )" - это UseCase Interactor. А где код, который выполняет роль InputPort и OutpputPort?

Я не пытаюсь осуждать прочитанное Вами, но я и не обязан это принимать/изучать, мне все равно кто там In/Out port. Любой опытный программист придумывает свою такую/подобную систему

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

Да, бизнес-логика (как коряво это звучит), должна подготовить и передать все данные для UI, обычно в виде структуры. Да, если UI переделывается и эти данные меняются - нужно вносить изменения в слой бизнес-логики. Какой-то полной/абсолютной "независимости" не существует. Важно что бизнес-логика не завязана на использование этих переданных данных. Хорошая проверка: а будет ли бизнес-логика работать без UI, напр с командной строкой?

0

Сообщение от Igor3D Да, если UI переделывается и эти данные меняются - нужно вносить изменения в слой бизнес-логики.

В достаточно крупном приложении имеет смысл выделить "уровень приложения".

Уровень данных - "бездумное" сохранение сущности.
Уровень бизнес-логики - сохранение сущности с учётом бизнес-правил и инвариантов.
Уровень приложения - сохранение сущности, специфичное для данного приложения (включая маппинг сообщений об ошибках и прочее).

0

Сообщение от Igor3D Я не пытаюсь осуждать прочитанное Вами, но я и не обязан это принимать/изучать, мне все равно кто там In/Out port. Любой опытный программист придумывает свою такую/подобную систему

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

Добавлено через 2 минуты

Сообщение от Igor3D Да, бизнес-логика (как коряво это звучит) ...

Согласен, звучит очень коряво. Буквально пару дней назад обсуждали это с коллегами.
А как назвать по другому? Было предложение назвать "деловая логика" или "предметная логика" - это и по сути ближе и звучит более "по русски".

Добавлено через 2 минуты

Сообщение от Shamil1 В достаточно крупном приложении имеет смысл выделить "уровень приложения". Уровень данных - "бездумное" сохранение сущности. Уровень бизнес-логики - сохранение сущности с учётом бизнес-правил и инвариантов. Уровень приложения - сохранение сущности, специфичное для данного приложения (включая маппинг сообщений об ошибках и прочее).

А что значит "сохранение сущности"?
Обычно для сохранения используется репозиторий. Вы имеете ввиду репозиторий?

Добавлено через 43 минуты
Кстати...
В моей задаче есть требование отображать ход выполнения в виде таблицы.
Если бизнес-слой будет отдавать клиенту только данные о каждой выполненной операции, то откуда на клиенте возьмется таблица? Значит, таблицу какой-то модуль должен создавать. Как мне кажется, интерфейс не должен заниматься созданием таблицы.

Может быть действительно надо использовать репозиторий?
Например, всю информацию о ходе выполняемых действий записывать в слое бизнес-логики в репозиторий, и отдавать клиенту список из этого репозитория?

0

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

Да не будет оно так просто, прочитал и применил. При проектировании классов раздумья неизбежны, и "теория" (или чужой опыт) может как помогать, так и мешать. Я верю что человек на хабре написал статью честно, и в его проекте все хорошо легло/получилось. Но это совершенно не значит что у Вас тоже будет так. Пока я вижу Вам угрожает чрезмерно теоретизированная, слишком абстрактная система с массой заглушек (не помню как называется этот антипаттерн).

Сообщение от zelenprog В моей задаче есть требование отображать ход выполнения в виде таблицы. Если бизнес-слой будет отдавать клиенту только данные о каждой выполненной операции, то откуда на клиенте возьмется таблица? Значит, таблицу какой-то модуль должен создавать. Как мне кажется, интерфейс не должен заниматься созданием таблицы.

Почему не должен? Что здесь плохого, и почему UI не может этим заняться? Какие аргументы кроме "так кажется"? Хотя возможно это и дело расчетной части (пресловутой бизнес-логики). И выделение отдельно - тоже свои резоны. Во всех 3 случаях нельзя сказать "это ошибка".

0

Сообщение от zelenprog А что значит "сохранение сущности"?

Работа в приложении сводится к изменению данных. Чаще всего это сохранение в БД.

Репозиторий (или аналоги) - это "бездумное" сохранение. По сути - это отображение сущности на таблицу.

Сообщение от zelenprog Как мне кажется, интерфейс не должен заниматься созданием таблицы.

Именно интерфейс и должен заниматься созданием html-таблицы.

Сообщение от zelenprog Например, всю информацию о ходе выполняемых действий записывать в слое бизнес-логики в репозиторий, и отдавать клиенту список из этого репозитория?

Лучше не писать в БД ненужную информацию. И вообще, бизнес-логика не должна знать, как и что выводится в интерфейсе.

0

Сообщение от Shamil1 Именно интерфейс и должен заниматься созданием html-таблицы.

html нет, но какую-то "data model" на базовых контейнерах вполне можно слить и в расчеты

Сообщение от Shamil1 И вообще, бизнес-логика не должна знать, как и что выводится в интерфейсе.

Безусловно. А обратное? Как-то выходит что "UI все знает"

0

Сообщение от Shamil1 Репозиторий (или аналоги) - это "бездумное" сохранение. По сути - это отображение сущности на таблицу.

Сообщение от zelenprog Уровень бизнес-логики - сохранение сущности с учётом бизнес-правил и инвариантов. Уровень приложения - сохранение сущности, специфичное для данного приложения (включая маппинг сообщений об ошибках и прочее).

Понял. Вы имеете ввиду разные "уровни" сохранения?
Только не совсем понял про сохранение на уровне приложения. Что значит "маппинг сообщений об ошибках"? Что такое "прочее"? Можно пример?

Добавлено через 8 минут

Сообщение от Shamil1 >> ... всю информацию о ходе выполняемых действий записывать в слое бизнес-логики в репозиторий, и отдавать клиенту список из этого репозитория? Лучше не писать в БД ненужную информацию. И вообще, бизнес-логика не должна знать, как и что выводится в интерфейсе.

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

Добавлено через 1 минуту

Сообщение от Shamil1 Именно интерфейс и должен заниматься созданием html-таблицы.

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

Добавлено через 2 минуты

Сообщение от Igor3D Пока я вижу Вам угрожает чрезмерно теоретизированная, слишком абстрактная система с массой заглушек (не помню как называется этот антипаттерн).

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

0

Сообщение от zelenprog является ли информация о выполняемых действиях частью бизнес-логики? И должна ли она сохраняться?

Если это указано в описании Системы (требованиях к Системе), то да.

Сообщение от zelenprog Вы имеете ввиду разные "уровни" сохранения?

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

Сообщение от zelenprog Что значит "маппинг сообщений об ошибках"?

Предположим, мы вызываем метод уровня приложения для создания документа. В этом методе вызывается метод бизнес-логики, который, в свою очередь, вызывает метод репозитория. Этот метод возвращает исключение с текстом, который, возможно, понятен только программисту. Например, "The DELETE statement conflicted with the FOREIGN KEY constraint ..." Метод в бизнес-логике перехватывает это исключение и возвращает исключение с текстом, понятным тому, кто будет разбираться с этой ошибкой (например, сотруднику службы поддержки). При необходимости, это сообщение пишется в лог, но показывать этот сообщение пользователю бессмысленно и даже вредно. Ему нужно вернуть сообщение (на нужном языке), отвечающее на три вопроса: что случилось? почему? что делать? Наиболее важен ответ на последний вопрос (что делать?). Причём, текст сообщения в интерфейсе пользователя, скорее всего, будет отличаться от текста сообщения в интерфейсе оператора или администратора

0

Сообщение от zelenprog Верно я рассуждаю?

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

0