1

私はワークフローサービスとWPFの調査段階にあります。

ステートマシンWFサービスをIISでホストし、1つ以上のWPFクライアントがWFサービスと通信することは、これまでのところ妥当な選択のように思われます。

ただし、何日も読んで調査したものの、WPFアプリから状態間の転送を追跡するための最良の戦略が何であるかは私にはわかりません。

参加者を追跡するサンプルは多数ありますが、それらのほとんどは1つのプロセスシナリオに基づいています。

なので、以下のような構造を考えています。

  1. クライアント側のエンドポイントを登録するためにクライアントが呼び出すサーバー側のWCF操作
  2. 登録されているすべてのクライアント側エンドポイントを通過し、Track（）メソッドでTrackingRecordを送信するカスタム追跡参加者。

このアプローチの利点は、ETWのような余分なレイヤーなしで状態をリアルタイムで更新できることです。もう1つの利点は、プレゼンテーション層からロジック（またはモデル層）を分離できることです。

上記の構造について誰かが意見を共有できますか？また、目標を達成するための提案を歓迎します。

[編集]上記の私の考えをより詳細かつ明確にするために、以下の手順が典型的な使用法です。

1）（WPFクライアント）には、TrackRecordを受信するためのWCFエンドポイントが含まれていて開きます。

2）（WFサービス）は、クライアント側のアドレスを内部ストアに登録するWCF操作（または受信メッセージを含む単純なWFインスタンス）を開きます。

3）（WFサービス）カスタム追跡参加者が作成および追加され、登録されたクライアントのエンドポイントにTrackingRecordが送信されます。

4）（クライアント）は上記のサービスに接続し、ステップ1で説明したクライアント側のエンドポイントを配布し、その結果、TrackingRecordsを受信します。

[編集2]

簡単に言えば、知りたいのですが

1）TrackingParticipantを介してWFサービス（IIS）+WPFまたは任意の種類のクライアントアプリでStateMachineの状態を追跡する最も効率的な方法。

2）私の提案を改善できるかどうか

その間、私はこれを実装し、これまでのところうまく機能しています。また、クライアント側にMvvM Lightフレームワークのメッセージング機能を追加して、受信したメッセージをモデルに簡単に伝達できるようにしました。

4

2 に答える 2

0

あなたが提案している多くの機能をラップする既存のメカニズムがあります（私があなたのニーズを正しく理解している場合）。WCFサービスを利用して双方向で通信する必要がある場合（つまり、接続されたクライアントにデータをプッシュする場合）、PollingDuplexバインディングを活用することをお勧めします。

私はPollingDuplex過去にさまざまなSilverlightクライアントでデータを交換するために使用しましたが、WPF空間で同じ動作を生成する手順を説明するこのような記事を読んだことがあります。

このアプローチにより、手動で実行することを考えていると思われるエンドポイントの登録と追跡のロジックの多くが自動化されます。

これがお役に立てば幸いです。

于 2012-11-07T14:27:22.250 に答える
0

WCFを強制的にpub/subプラットフォームにするのではなく、SignalRを検討することもできますが、これはその強みではありません。私のブログには、追跡アプリケーションから分割された追跡参加者を含む視覚的な追跡の例があるため、すべてが1つのプロセスに含まれているわけではありません。そのブログには、同様のことが行われた他の2つのブログへのリンクもありますが、すべてこのようなイベントにより適したメッセージングアーキテクチャを使用しています。

http://panmanphil.wordpress.com/2012/11/05/slides-and-sample-from-the-chippewa-valley-code-camp/

于 2012-11-18T13:04:09.487 に答える