4

サーバーからファイルを取得して別のサーバーに移動するアプリを構築する必要があります。Windows Workflow Foundation (WF) の使用を検討するよう提案されました。

ワークフローの構築を開始しましたが、ごちゃごちゃになっていて、可能な限り最善の方法で行っているかどうかわかりません。

基本的なワークフロー アクティビティは次のとおりです。

ソースのリストを取得する ソースが ftp かディスク ドライブかを判断する サーバーからファイルのリストを取得する ソースが ftp の場合は、ftp でファイルを取得する ソースがドライブの場合は、ドライブからファイルを読み取る ターゲットが ftp の場合は、ftp ファイルをサーバー ターゲットがドライブの場合はドライブに書き込み ターゲットが Web サービスの場合は Web サービスに投稿 ソースが ftp の場合は ftp コマンドでファイルを削除 それ以外の場合はソースがドライブの場合はファイルを削除

1 つのワークフローでは、少し忙しくなります。2 つの while ループが必要です。1 つは統合の周りで、もう 1 つはファイル リストを取得した後に必要です。

他に考えたことは、複数のワークフローを構築することでした。FTPtoFTP、FTPtoDrive、FTPtoWebServie、DriveToFTP、DrivetoDrive、DriveToWebService 用の 1 つ。

助言がありますか？

4

4 に答える 4

3

まず、主要なセクションごとにカスタム アクティビティを作成することを検討する必要があります。カスタム アクティビティは、多くのステップで構成できる複合アクティビティになります。これにより、物事が少し整理され、比較的高いレベルでワークフローを引き続き使用できるようになります。

ワークフロー デザイナは便利ですが、非常に大規模に拡張できるようには設計されていません。VS 2008 の時点で、XAML ベースのテクノロジを操作する最善の方法は、テキスト エディターを使用して XML を直接読み書きすることです。

いくつかの高レベルのアクティビティに分割でき、XAML レベルで作業していない限り、複数のワークフローに分割することは最善の方法ではない可能性があります。これらすべてのロジックとフローがほぼ同じである場合、6 つの異なるワークフローを維持する必要があることに注意してください。ワークフローが複雑で、ワークフロー全体で共通のロジック エラーを修正する必要がある場合、これはさらに大きな悪夢です。

また、サービスの使用についても考慮する必要があります。これにより、1 つのワークフローと 1 つのアクティビティ セットを持つことができますが、各ステップの実装はサービスに分離できます。この場合、組み合わせごとに 1 つのワークフローをインスタンス化し、同じワークフローをそれぞれにロードして、異なるアクティビティを挿入する必要があります。必ずしも最善のアプローチではありませんが、考慮すべきことがあります。

于 2009-04-13T15:28:50.157 に答える
3

まず第一に、これは WF を使用すると、かなり単純なプロセスであるはずのプロセスがさらに複雑になるように思えます。WF は実行フローのモデル化に使用できますが、その目的はビジネス フローをモデル化し、実装に組み込むことなくビジネス ルールとロジックを含めることです。

あなたの例では、ビジネス ルールは app.config ファイルで処理する必要があるもののように見えます。

ただし、1 つまたは複数のワークフローを使用するというより広範な問題については。各ワークフロー タスクをほぼ同じ「広い範囲」にする必要がある

たとえば、テーブルを構築するための WF

  • 木材を購入する
  • 木を切る
  • 脚用の木を切る
  • ベベル エッジ
  • 丸いコーニス
  • 異なる粗さで2回研磨します
  • テーブルを組み立てる

中央のステップはすべて、その周りのステップよりもはるかに詳細です。したがって、大まかな手順を含む高レベルのワークフローと、詳細を含む低レベルのワークフローの 2 つの別個のワークフローに分割することを検討してください。

したがって、「GetDatasource」ワークフロー ステップは、収集元のデータ ソースのタイプを (外部的に) 気にせず、一連のデータをワークフローの次のステップに戻すだけです。

ターゲットにも同じことが言えます。データソースのタイプは気にせず、データとの関係のみを気にします。したがって、それもカプセル化する必要があります。

したがって、ワークフローは 3 つのワークフローになる可能性があります

最高WF

  1. GetDataSourceWF
  2. DoThingsWithDataWF

その後、DoThingsWithDataWF および GetDataSourceWF ワークフローはそれぞれ、必要な実行コンテキストのみを扱うことができます。

編集

コメンターのJames Schekが指摘したように。上位レベルのワークフローを使用して、下位レベルのワークフローを実際に開始し、それらの実行を相互に管理できます。

于 2009-04-13T15:30:48.373 に答える
0

個人的には、まだ WWF を使用していません。しかし、私は以前にかなりのワークフローを行ってきました。私には、それらをより小さなワークフローに分割することが最善の方法のように思えます。ワークフローで作業するときは、各ワークフローを特定のタスクに制限して、確実な開始アクションと、少なくとも 1 つの成功したルートと少なくとも 1 つの失敗したルートを持つようにする必要があります。一般に、ワークフローは非常に扱いにくいものになる可能性があるため、それぞれをできるだけシンプルに保つことが最善です。

于 2009-04-13T15:04:36.967 に答える
0

原則として、物事が「ぐちゃぐちゃ」になったときはいつでも、それらをより小さな部分に分解する必要があります。いくつかのワークフローに分割することを強くお勧めします。

于 2009-04-13T15:10:03.257 に答える