Триггеры событий на основе таймера

Question

В настоящее время я работаю над проектом с определенными требованиями.Краткий обзор их заключается в следующем:

• Данные извлекаются из внешних веб-сервисов
• Данные хранятся в SQL 2005
• Управление данными осуществляется с помощью веб-графического интерфейса
• Служба Windows, которая взаимодействует с веб-службами, не имеет связи с нашим внутренним веб-интерфейсом, кроме как через базу данных.
• Взаимодействие с веб-сервисами должно осуществляться как по времени, так и посредством вмешательства пользователя в веб-интерфейс.

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

1) Адаптируйте таблицу триггеров для хранения двух дополнительных параметров.Один из них: "Зависит ли это от времени или добавлено вручную?" и поле с возможностью обнуления для хранения сведений о времени (точный формат будет определен позднее).Если это триггер, созданный вручную, пометьте его как обработанный при срабатывании триггера, но не в том случае, если это синхронизированный триггер.
или
2) Создайте вторую службу Windows, которая создает триггеры "на лету" с заданными интервалами.

Второй вариант кажется мне выдумкой, но управление вариантом 1 может легко превратиться в кошмар программирования (откуда вы знаете, вернул ли последний опрос таблицы событие, которое должно сработать, и как вы тогда остановите его повторный запуск при следующем опросе)

Я был бы признателен, если бы кто-нибудь уделил несколько минут, чтобы помочь мне решить, каким маршрутом (одним из этих двух или, возможно, третьим, не включенным в список) воспользоваться.

Answer 1

Почему бы не использовать задание SQL вместо службы Windows?Вы можете инкапсулировать весь "триггерный" код вашей базы данных в Хранимые процедуры.Затем ваш пользовательский интерфейс и задание SQL могут вызывать одни и те же хранимые процедуры и создавать триггеры одинаковым образом, будь то вручную или с определенным интервалом времени.

Answer 2

Я вижу это так.

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

Таким образом, вы также можете использовать эти классы непосредственно из WebUI и импортировать данные на основе триггера WebUI.

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

Вы даже можете преобразовать весь код в исполняемый файл, который затем можно запланировать с помощью планировщика Windows.И вызывайте один и тот же exe-файл всякий раз, когда пользователь запускает действие из веб-интерфейса.

Answer 3

@Vaibhav

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

* Разве не всегда так, что технически "лучшее" решение загоняется в тупик внешними факторами?