Где сохранить бизнес-логику для веб-приложения для анализа данных с большим количеством взаимодействия с пользователем - PullRequest
Новая
       43

Где сохранить бизнес-логику для веб-приложения для анализа данных с большим количеством взаимодействия с пользователем

0 голосов
/ 14 сентября 2018

Я пытаюсь создать веб-приложение, в котором:

  • Пользователю в браузере показана таблица (назовите ее table0) со строками (около 1000-1500 строк) и несколькими (5-6) столбцами.
  • В зависимости от данных в таблице 0, 3-4 новые таблицы создаются на основе некоторой бизнес-логики.
  • Пользователь вносит некоторые изменения (добавление строк, удаление строк, изменение существующих значений строк для определенных столбцов) только в table0. Здесь изменений, внесенных пользователем, может быть много, и соответствующие изменения должны динамически отражаться во всех последующих (сгенерированных) таблицах (поэтому, как только он внесет некоторые изменения в table0, он должен немедленно увидеть обновленную версию). новых таблиц).

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

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

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

1 Ответ

0 голосов
/ 16 сентября 2018

Здесь нет серебряных пуль.То, с чем вы имеете дело, - это компромисс между доступностью и согласованностью .

Если согласованность важнее:

  • Когда пользователь заканчивает редактирование основной таблицы, вы делаете запрос с изменениями в бэкэнд.Затем серверная часть обновит основную таблицу и сгенерированные таблицы.Затем бэкэнд возвращает клиенту внешнего интерфейса 200 Ok.
  • Внешний интерфейс ожидает, и после получения 200 Ok из предыдущего запроса он получает обновленные сгенерированные таблицы из внутреннего интерфейса с помощью дополнительных запросов (это можно оптимизировать на основеваша бизнес логика).
  • Если ваши требования к постоянству позволяют это, взгляните на материализованные представления для создания и ведения сгенерированных таблиц.
  • Главный недостаток заключается в том, что этот подход медленнее.

Если доступность важнее:

  • Когда пользователь заканчивает редактирование основной таблицы, вы выполняете запросы с изменениями во внутреннем интерфейсе.Бэкэнд работает с логикой обновления.
  • Вы не блокируете на фронте и ждете 200 Ok от бэкэнда, но обновите вручную сгенерированные таблицы во внешнем интерфейсе.
  • Этот подход работает отлично, так как первый запрос к бэкэнду не завершается неудачей.Если этот запрос не будет выполнен, ваш веб-интерфейс отобразит противоречивые данные.
  • Еще один недостаток этого подхода заключается в том, что бизнес-логика будет скрываться во внешнем интерфейсе и, скорее всего, также будет дублироваться на бэкэнде.
  • Такой подход позволит улучшить взаимодействие с пользователем.
...