基于事件的触发器

2018-06-20 10:29:09

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

数据从外部Web服务中检索

数据存储在SQL 2005中

数据通过Web GUI进行操作

与Web服务通信的Windows服务与我们的内部Web UI无关，除了通过数据库。

与Web服务的通信需要基于时间，并通过用户在Web UI上的干预来触发。

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

1）调整触发器表来存储两个额外的参数。一个是“这是基于时间还是手动添加？” 和一个可为空的字段来存储时间细节（确切格式待定）。如果它是一个经过手工创建的触发器，则在触发器被触发时将其标记为已处理，但如果它是定时触发器则不予处理。
要么
2）创建第二个Windows服务，以定时的间隔即时创建触发器。

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

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

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

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

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

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

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

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

@Vaibhav

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

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

链接地址: http://www.djcxy.com/p/57473.html