質問

現在、特定の要件を持つプロジェクトに取り組んでいます。これらの概要は次のとおりです。

  • データは外部 Web サービスから取得されます
  • データは SQL 2005 に保存されます
  • データはWeb GUI経由で操作されます
  • Web サービスと通信する Windows サービスは、データベース経由を除き、内部 Web UI と連携していません。
  • Web サービスとの通信は、時間ベースであることと、Web UI でのユーザー介入によってトリガーされることの両方が必要です。

Web サービス通信トリガーの現在の (本番前) モデルは、手動介入によって生成されたトリガー リクエストを保存するデータベース テーブルを介しています。実際には複数のトリガー メカニズムを使用するつもりはありませんが、呼び出しの時間に基づいてデータベース テーブルにトリガーを設定できるようにしたいと考えています。私が見たところ、これを実現するには 2 つの方法があります。

1) トリガー テーブルを調整して、2 つの追加パラメーターを保存します。1つは「この時間ベースですか、それとも手動で追加されていますか?」です。タイミングの詳細を保存するための無駄なフィールド(決定する正確な形式)。手動で作成したトリガーの場合は、トリガーが起動されたときに処理済みとしてマークしますが、時間指定トリガーの場合はそうではありません。
または
2) 一定の間隔でオンザフライでトリガーを作成する 2 番目の Windows サービスを作成します。

2 番目のオプションは私にはごまかしのように思えますが、オプション 1 の管理は簡単にプログラミングの悪夢に変わる可能性があります (テーブルの最後のポーリングが、起動する必要があるイベントを返したかどうかをどのようにして知り、その後、それをどのように停止するのでしょうか)次のポーリングで再トリガー)

どちらのルート (これら 2 つのうちの 1 つ、または場合によってはリストにない 3 番目のルート) を選択するかを決定するのに数分時間を割いていただける方がいらっしゃいましたら幸いです。

役に立ちましたか?

解決

Windows サービスの代わりに SQL ジョブを使用してみてはいかがでしょうか?データベースの「トリガー」コードをすべてストアド プロシージャにカプセル化できます。そうすれば、UI と SQL ジョブは同じストアド プロシージャを呼び出し、手動でも時間間隔でも同じ方法でトリガーを作成できます。

他のヒント

私の見方はこうです。

スケジューラの役割を果たす Windows サービスがあり、その中には単に Web サービスを呼び出してデータベースにデータを入れるクラスがいくつかあります。

したがって、これらのクラスを WebUI から直接使用して、WebUI トリガーに基づいてデータをインポートすることもできます。

私は、ユーザーが生成したアクションをフラグ (トリガー) としてデータベースに保存し、そのアクションを実行するために何らかのサービスが (ユーザーの制御下にない間隔で) それをポーリングするという考えが好きではありません。

コード全体を exe に変換し、Windows スケジューラを使用してスケジュールすることもできます。ユーザーが Web UI からアクションをトリガーするたびに、同じ exe を呼び出します。

@Vaibhav

残念ながら、ソリューションの物理アーキテクチャでは、Web UI からデータベース、およびデータベースからサービス (Web サービスを呼び出すことができる) 以外のコンポーネント間の直接通信は許可されません。ただし、ここではコミュニケーション クラスの再利用が理想的であることに同意します。私たちのビジネスの範囲内ではそれはできません*

*技術的に「より良い」ソリューションは、外部要因によって妨げられるのが常ではないでしょうか?

ライセンス: CC-BY-SA帰属
所属していません StackOverflow
scroll top