Дизайн приложения: Предоставление метаданных объекта?

Question

Этот вопрос может быть довольно широким, но я надеюсь на какой-то ответ, который может подтолкнуть меня в каком-то направлении.

Допустим, я создаю календарь событие .Клиент извлекает события с сервера.Каждое событие имеет дату , и после того, как дата прошла, событие состояние считается выполнено .Таким образом, есть некоторая логика, связанная с определением, выполнено ли событие или нет, в этом примере это просто.Представьте, что уровень логики намного более сложный, где приложение должно выполнять эту логику?

Вариант 1 - Хранить в базе данных

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

Вариант 2. Сохранение логики на сервере

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

Вариант 3 - Сохранить логику на клиенте

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

Answer 1

Сосредоточив внимание на производительности, я предлагаю сохранить на сервере, но использовать средство запуска задач для выполнения какой-либо функции в фоновом режиме каждую минуту и ​​загрузки событий из кэша или очереди.Каждое новое событие должно публиковаться в кеше, таком как redis, который будет освобождать базу данных от множества запросов каждый раз, когда процедура проверяет дату событий, чтобы завершить их, просто используя базу данных для обновления данных.Вы также можете использовать Очередь вместо Redis, чтобы держать событие в курсе рутины и выскакивать его, когда закончите.Эта процедура может использовать домен совместно с основным приложением, чтобы избежать избыточности логики.

Answer 2

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

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