Могу ли я сохранить System.Timers.Timer в ObjectCache для последующего доступа? - PullRequest
0 голосов
/ 30 августа 2018

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

  1. Когда пользователь запускает новое приложение, запускается 5-минутный таймер.
  2. Если пользователь вносит какие-либо изменения в приложение до истечения 5 минут, таймер отменяется.
  3. Если таймер запускается до конца, нашей компании отправляется электронное письмо («приложение было создано, но оставлено»).

Веб-сервер для этого проекта - это проект .NET MVC, хотя все контроллеры, кроме Home Controller, наследуются от System.Web.Http.ApiController, а не System.Web.Mvc.Controller. Передняя часть угловая 6.

Кажется, достаточно просто запустить 5-минутный таймер, который будет выполнять метод «отправки по электронной почте» через 5 минут. Я застрял на том, как реализовать возможность отмены таймера, если пользователь редактирует приложение до того, как таймер закончится. Команда для запуска приложения и любые последующие изменения будут поступать как отдельные запросы к API, поэтому я не поддерживаю никакого состояния от вызова к вызову.

Моя текущая идея - создать таймер с помощью System.Timers.Timer при запуске приложения и сохранить таймер в ObjectCache под уникальным идентификатором, представляющим это конкретное приложение. Затем, когда вызывается действие редактирования, я могу проверить кэш, чтобы увидеть, хранится ли таймер, соответствующий редактируемому приложению, и, если это так, отменить таймер. Если такой звонок не поступит в течение 5 минут, таймер сработает и электронное письмо будет отправлено.

Будет ли это работать? (Как возможность доступа к таймеру, чтобы отменить его, так и срабатывание таймера, как ожидалось, если не отменено?) Существует ли лучший или более подходящий для .NET способ реализации этого требования? Извиняюсь за неопределенную сферу этого вопроса; Мне не повезло с Google или поиском ТАК, хотя моё незнакомство с работой с таймерами может мешать моим поискам.

Спасибо!

1 Ответ

0 голосов
/ 30 августа 2018

Корень вашей проблемы в архитектуре. Вероятно, вам следует больше задуматься о том, как спроектирован ваш сервер и как клиентский дизайн и серверный дизайн дополняют друг друга. Для начала постоянное состояние, возможность запуска некоторых фоновых задач и использование функциональных возможностей блокировки (таких как ключевое слово lock в C #) при доступе к этому постоянному состоянию помогут создать более расширяемый и гибкий дизайн. Как вы проектируете эти функции и как взаимодействует ваша клиентская сторона, решать только вам. Один из подходов состоит в том, чтобы заставить контроллер API выполнять запись в постоянное состояние, используя блокировку для предотвращения одновременной записи, а затем использовать фоновую задачу, чтобы отслеживать это постоянное состояние и запускать определенные действия при необходимости. Поиграйте с дизайном и выясните, что работает для ваших нужд. Удачи в вашем приложении.

...