2

特に、私が興味を持っているのは: 1)ワークフローを実行するための無料の環境をセットアップすること。2) 既存のワークフロー アイテム/状態の使用方法とそれに関連するもの。

ありがとう！

4

2 に答える 2

6

他の答えは良いですが、ワークフローを使用する理由を理解することが重要だと思います。多くの人は、必要のないときに WF を使用しますが、WF の使用に最適なユースケースであるにもかかわらず、使用を拒否する人もいます。

WF を使用するタイミングと使用するかどうかについて、これまでに読んだ中で最も適切な説明は、Dave Green のブログ投稿です。彼は、Windows Workflow Foundation の最初のバージョンのアーキテクトでした。

後世のためにここに貼り付けます：

ワークフローとは何ですか? なぜ気にするのですか?

もちろん、ワークフローという言葉は、コミュニケーションを妨げてしまう、非常に過負荷な用語の 1 つです。

ワークフローは、たった 2 つのアイデアに帰着します。1 つは、ワークフローが動作の不透明な単位と見なす、実行すべき作業があるということです。フローは、どの作業がいつ行われるかを示します。

これはワークフローですか？

public void HandleLoanRequest (string customerID, Application app)
{
    if (CheckCredit(customerId, app.Amount))
    {
        MakeOffer (customerId, app);
    }
}

はい、そう思います。この作業は、顧客の信用を確認してオファーを行うことです。HandleLoanRequest は、この作業を実行するかどうか、およびいつ実行するかを定義します。

しかし、ワークフロー ベンダーが伝統的に、勝利を宣言する前にこの種のコード以上の何かが必要であると感じてきたという事実は、重要な概念がまだ欠けていることを示唆しています。

これは、フローを説明するだけでなく、検査、推論、および操作できる方法で説明する必要があるということだと私は信じています。つまり、ワークフローにはモデルが必要です。

C# はこれを行う 1 つの方法です。たとえば、ワークフロー コードをスキャンしてフローのグラフを描画できるコーディング標準を定義できます。または、開発者がモデルを形成するコードの部分を呼び出すために使用する属性を定義することもできます。これは、私たちが Windows Workflow Foundation のために行った選択ではありません。なぜこのような選択をしたかについては、後の投稿で説明しますが、うまくいくでしょう。

しかし、モデルが必要な理由に戻りましょう。私たちはそれを作成するために努力をしなければなりません。見返りはどこ？（または、海外のこの英国人がそれを呼ぶことを学んでいるように、牛肉）。

まあ、見返りはモデルが可能にするものから来ると思います-

可視化 開発中とメンテナンス中の両方の開発者に役立ちますが、要求されたことを実行する必要がある理由を知りたいワークフロー ユーザーや、どのような不正行為が行われたかを知りたい IT 運用担当者にも役立ちます。アプリは最大であるか、最大である必要があります。

表現力 ワークフロー モデルはドメイン固有言語であり、特徴的な問題をサポートするために特化されています。例として、5 回のレビューのうち 3 回の肯定的な投票がドキュメントが良好であることを意味するレビュー プロセスが挙げられます。未処理のレビューはすべて取り消すことができます。これはコーディングが少し面倒ですが、Windows Workflow Foundation には、このような問題に対処するすぐに使用できる構造が含まれています。

実行 ランタイムはモデルを利用して、同じ問題を何度も解決する必要をなくすことができます。Windows Workflow Foundation では、単純で表現力豊かなモデル要素によって制御される、状態管理や補正など、長時間実行されるワークフローの複雑な問題のサポートを組み込みました。

監視 モデルが存在することで、開発者の追加の労力を必要とせずに、意味のある意味を持つイベント ストリームを生成できます。これを使用して、ワークフローのインスタンスまたは集計を監視できます。Windows Workflow Foundation では、ワークフロー状態から引き出されたアプリケーション データを使用してイベントを宣言的に装飾することもできます。これにより、注文 14532 の信用調査が開始されたことを確認できます。

変換 モデルはモデルを生みます。その一例は、ワークフロー モデルを、それと通信するために必要なメッセージ交換パターンに変換することです。Dharma と Don が PDC で見事に実演したように。もう一つはカスタマイズです。ISV は、VAR によってカスタマイズされたワークフローを出荷し、顧客によって再度カスタマイズされます。その後、ISV は新しい基本バージョンを出荷します。よく理解された共有モデルをワークフローに使用すると、結果として生じる 3 方向のマージがはるかに扱いやすくなります。

構成 アプリケーションがフローと作業に分割されている場合、作業のアトミック要素は、よく理解されたインターフェイスを使用して、他のワークフローで再利用できます。ワークフロー自体は、他のワークフローでも使用できる作業の有効な定義です。

カスタマイズと変換を組み合わせることで、作業とフローの定義が共有または取引される成果物になるエコシステムが実現します。

操作 多くの場合、ワークフローをその場で作成または変更する必要があります。これがコードの変更を意味する場合、ユーザーがコードのハッキング方法を理解していたとしても、セキュリティ担当者に問題が発生することになります。モデルを使用すると、制御可能でわかりやすい動的操作が可能になります。Windows Workflow Foundation は、ワークフロー タイプとワークフロー インスタンスの両方の動的な変更をサポートしています。

以上です（少なくとも、今週の土曜日の午後、私の頭に浮かんだことはすべてです）。これが、モデルが優れたアイデアであると考えた理由であり、モデルの ROI が優れていると考える理由です。しかし、これらの利点のいずれもシナリオに当てはまらない場合でも、コーディングは依然として非常に優れています。

于 2011-04-17T16:28:06.063 に答える
3

MSDNのこのような仮想ラボをお探しですか?

ハウツーについては、Windows Workflow Foundation のハンズオン ラボをダウンロードしてみてください。

于 2008-10-07T03:52:56.217 に答える