我目前正在开发一个具有特定要求的项目。这些的简要概述如下：
用于Web服务通信触发的当前（预生产前）模型是通过存储从手动干预生成的触发请求的数据库表。我真的不想拥有多个触发机制，但希望能够根据调用时间使用触发器填充数据库表。我认为有两种方法可以实现这一目标。
1）调整触发表以存储两个额外参数。一个是“这是基于时间还是手动添加？”和可空字段来存储时序细节（确切的格式）。如果它是一个手动创建的触发器，则在触发器触发时将其标记为已处理，但如果是定时触发器则不会。
或
2）创建第二个Windows服务，以定时间隔即时创建触发器。
第二个选项对我来说似乎是一种软糊涂，但是选项1的管理很容易变成编程噩梦（你怎么知道表的最后一次轮询是否返回了需要触发的事件，你怎么知道然后停止在下次投票中重新触发）
如果有人能花几分钟时间来帮助我决定选择哪条路线（这两条路线中的一路，或者可能是第三条未列出的路线），我会很感激。
答案 0 :(得分：2)
为什么不使用SQL作业而不是Windows服务？您可以在存储过程中封装所有db“trigger”代码。然后，您的UI和SQL作业可以调用相同的存储过程，并以相同的方式创建触发器，无论是手动还是按时间间隔。
答案 1 :(得分：0)
我看到它的方式就是这个。
您有一个Windows服务，它扮演调度程序的角色，其中有一些类只调用Web服务并将数据放入数据库。
因此，您也可以直接从WebUI使用这些类，并根据WebUI触发器导入数据。
我不喜欢将用户生成的操作存储为数据库中的标志（触发器）的想法，其中某些服务将轮询它（以不受用户控制的间隔）来执行该操作。
您甚至可以将整个代码转换为exe，然后可以使用Windows Scheduler进行调度。每当用户从Web UI触发操作时调用相同的exe。
答案 2 :(得分：0)
@Vaibhav
不幸的是，解决方案的物理体系结构不允许组件之间的任何直接通信，除了Web UI到数据库，以及数据库到服务（然后可以调用Web服务）。但是，我确实同意重复使用通信类是理想的 - 我不能在我们的业务范围内做到这一点*
*技术上“更好”的解决方案是否总是被外部因素阻碍？