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

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

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

1) 调整触发器表以存储两个额外参数。一个是“这个时间基于时间还是手动添加?”以及可存储正时详细信息的无效字段(要确定的确切格式)。如果它是手动创建的触发器,则在触发触发器时将其标记为已处理,但如果它是定时触发器,则不将其标记为已处理。
或者
2) 创建第二个 Windows 服务,以定时间隔动态创建触发器。

第二个选项对我来说似乎是一个谎言,但选项 1 的管理很容易变成一场编程噩梦(你如何知道表的最后一次轮询是否返回了需要触发的事件,以及如何停止它下次轮询时重新触发)

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

有帮助吗?

解决方案

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

其他提示

我的看法是这样的。

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

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

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

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

@Vaibhav

不幸的是,该解决方案的物理架构不允许组件之间进行任何直接通信,除了 Web UI 到数据库以及数据库到服务(然后可以调用 Web 服务)。然而,我确实同意重用通信类将是这里的理想选择 - 我只是无法在我们的业务范围内做到这一点*

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

许可以下: CC-BY-SA归因
不隶属于 StackOverflow
scroll top