Silverlightアプリケーションの検証にWindowsワークフローを使用するにはどうすればよいですか？
Windowsワークフローを使用して検証サービスを提供したいと思います。提供される検証には、検証の他の段階へのチェーンとリダイレクトを伴う複数の層が含まれる場合があります。検証用のデータを生成するアプリケーションはSilverlightアプリです。
検証には瞬く間に時間がかかると思いますので、ユーザーを拘束したくありません。代わりに、検証のために現在のデータを送信してほしい。検証が迅速に行われると、サービスはアプリへの非同期コールバックを実行します。呼び出しを行ったビューモデルは、検証出力を受け取り、ビューに投稿します。
検証に時間がかかる場合、ユーザーは検証の潜在的な出力を無視して、Silverlightアプリで先に進むことができます。呼び出しを行ったビューモデルはなくなります。モデルに現在の検証出力を含む別のビューモデルがあると思います。検証値が変更されると、ユーザーはより小さな通知領域で通知を受け取ります。
現在のビューのビューモデルが検証出力を含むビューモデルを介して検証を呼び出す方法を確認できますが、サービス呼び出しがタイムアウトするのではないかと心配しています。また、ユーザーが元の検証から値をすでに変更していて、フィードバックが無効になっている可能性があると思います。
非同期検証は何度も解決された問題であると確信しています。この種の問題を解決した経験から収集したいと思っています。
これは問題への正しいアプローチですか、それともこれにアプローチするためのより良い方法がありますか？
まず、Windowsワークフローで記述された検証サービスを提供するWCFサービスを使用しており、Silverlightクライアントがこのサービスを使用してある種のデータを検証したり検証操作を開始したりすることを前提としています。
このシナリオでは、長時間実行と短期実行の検証操作を分離し、それぞれに異なるUIフレームワークを提供する必要があります。 短時間実行検証は通常の非同期の要求-応答モデルで処理する必要があります。これは、ユーザーが検証の結果を（ブロックせずに）待機することを意味します。これは、ほとんどのSilverlightアプリケーションの通常のフローです。 長時間実行検証は別の方法で処理する必要があります。ユーザーに結果を待つように強制することはできません。 「通知メカニズム」を使用して、検証の結果を非同期でユーザーに通知し、検証でエラーまたは失敗が返された場合に操作を「編集」または「再送信」する方法を提供することをお勧めします。
言い換えると、Windows Workflowは、検証手順を「接着」するための単なる方法です。残りの設計と実装を処理する必要があります。