TPLデータフローを使用して最適なアーキテクチャを最適に設計する方法について意見を求めたいと思います。私はまだコードを書いていませんので、投稿できるサンプルコードはありません。私は(ボランティアでない限り)コードも探していませんが、設計の支援をいただければ幸いです。
要件は次のとおりです。
特定の方法で相互に依存している3つのコアデータブロックがあります。Datablock1は、タイプFoo1のオブジェクトを生成するプロデューサーです。Datablock2は(Datablock1からの)Foo1オブジェクトをサブスクライブすることになっており、潜在的に(特定の関数の対象となるすべてのFoo1にではなく)、他のデータブロックが消費するために出力キューに格納するFoo2オブジェクトを生成します。Datablock3は(Datablock1からの)Foo1オブジェクトも消費し、Datablock2が消費してFoo2オブジェクトに変換するFoo3オブジェクトを生成する可能性があります。
要約すると、データブロックとそれらがそれぞれ生成および消費するものは次のとおりです。
- Datablock1:Produces(Foo1)、Consumes(Nothing)
- Datablock2:Produces(Foo2)、Consumes(Foo1、Foo3)
- Datablock3:Produces(Foo3)、Consumes(Foo1)
追加の要件は、同じFoo1がDatablock2とDatablock3でほぼ同時に処理されることです。Foo1オブジェクトが最初にDatablock2によって消費され、次にDatablock2がその作業を完了すると、まったく同じFoo1オブジェクトがDatablock3に投稿されてその作業を実行する場合は問題ありません。Datablock2のFoo2オブジェクトは、Foo1オブジェクトまたはFoo3オブジェクトのいずれかの操作の結果として発生する可能性があります。
これが理にかなっていることを願っています。それでも不明な点がある場合は、さらに説明させていただきます。
私の最初のアイデアは、3つのデータブロックごとにTPLデータフローブロックを作成し、それらにさまざまなオブジェクトタイプの着信ストリームを処理させることでした。もう1つのアイデアは、データブロックを分割し、各データブロックが単一のオブジェクトタイプのストリームのみを処理するようにすることです。あなたは何をお勧めしますか、それともうまくいくかもしれないさらに良い解決策がありますか?
SvickはすでにDatablock1を支援しており、すでに運用されています。現在の環境(上記のとおり)をTPLDataflowに変換する方法に固執しています。
任意のアイデアやポインタは大歓迎です。