基于定时器的事件触发器

我目前正在制定一个具有特定要求的项目。简要概述如下:

  • 从外部网络服务
  • 检索数据
  • 数据存储在SQL 2005中
  • 通过网络图形用户界面操作数据
  • 与Web服务通信的Windows服务与我们的内部Web UI没有关系,除了通过数据库。
  • 与网络服务的通信需要基于时间,并通过用户在网络用户界面上的干预触发。

用于Web服务通信触发的当前(预生产)模型是通过存储从手动干预产生的触发请求的数据库表。我真的不想有多个触发机制,但希望能够根据调用时间使用触发器填充数据库表。正如我所看到的,有两种方法可以实现这一点。

1) Adapt the trigger table to store two extra parameters. One being "Is this time-based or manually added?" and a nullable field to store the timing details (exact format to be determined). If it is a manaully created trigger, mark it as processed when the trigger has been fired, but not if it is a timed trigger.
or
2) Create a second windows service that creates the triggers on-the-fly at timed intervals.

第二种选择对我来说似乎是一种欺骗,但是选项1的管理可能很容易变成编程的噩梦(你怎么知道表的最后一次投票是否返回了需要触发的事件,以及如何停止它重新触发下一轮投票)

如果有人能够腾出几分钟的时间来帮助我决定采取哪条路线(这两条路线中的一条,或者可能是三条路线中的一条),我将不胜感激。

0
额外 编辑
意见: 1

3 答案

我看到它的方式是这样的。

你有一个Windows服务,它扮演着一个调度程序的角色,并且有一些类只需调用Web服务并将数据放入数据库中。

因此,您也可以直接从WebUI使用这些类,并根据WebUI触发器导入数据。

我不喜欢将用户生成的操作作为标志(触发器)存储在数据库中的想法,在该数据库中,某些服务将轮询它(在不受用户控制的时间间隔内)以执行该操作。

你甚至可以将整个代码转换成一个exe文件,然后你可以使用Windows Scheduler进行安排。并且每当用户从Web UI触发操作​​时调用相同的exe。

0
额外

@Vaibhav

不幸的是,解决方案的物理架构不允许组件之间的任何直接通信,除了Web UI到数据库以及数据库服务(然后可以向Web服务发出呼叫)。不过,我确实认为重复使用通信类将是理想之选 - 我无法在我们的业务范围内做到这一点*

*技术上“更好”的解决方案是否受到外部因素的阻碍并不总是这样?

0
额外

为什么不使用SQL作业而不是Windows服务?你可以将所有的db“触发”代码封装在Stored Procedures中。然后,您的UI和SQL作业可以调用相同的存储过程,并以相同的方式创建触发器,无论是手动还是间隔。

0
额外