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

Question

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

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

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

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

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

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

Answer 1

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

Answer 2

Способ, которым я это вижу.

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

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

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

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

Answer 3

@Vaibhav

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

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