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

  • 从外部Web服务检索数据
  • 数据存储在SQL 2005中
  • 数据通过Web GUI进行操作
  • 与Web服务通信的Windows服务与我们的内部Web UI没有耦合,除了通过数据库。
  • 与Web服务的通信需要基于时间,并且通过Web UI上的用户干预来触发。

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

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

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

我很感激,如果有人可以花几分钟时间来帮我决定哪条路线(这两条路线中的一路,或者可能是第三条,未列出的路线)。

===============>>#1 票数:3 已采纳

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

===============>>#2 票数:0

我看到它的方式就是这个。

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

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

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

您甚至可以将整个代码转换为exe,然后可以使用Windows Scheduler进行调度。 每当用户从Web UI触发操作​​时,调用相同的exe。

===============>>#3 票数:0

@Vaibhav

遗憾的是,解决方案的物理体系结构将不允许组件之间的任何直接通信,除了Web UI到数据库,以及数据库到服务(然后可以调用Web服务)。 但是,我确实同意重复使用通信类是理想的 - 我不能在我们的业务范围内做到这一点*

*技术上“更好”的解决方案是否总是被外部因素阻碍?

  ask by ZombieSheep translate from so

未解决问题?本站智能推荐: