2017-05-10 7 views
0

私のアプリケーションが持つフローを制御するための確立パターンがあるかどうかは疑問です。簡単に言えば パイプライン/責任チェーンパターン

が、それはそのようなことのはずだ:

  • ユーザーが
  • ファイルが処理されているファイルを提供
  • ユーザーは

    いくつか存在します処理されたファイル

を受け取ります処理ステップは、 PreprocessingOne、PreprocessingTwo、PreprocessingThree、およびFinalProcessingと言うことができます。

もちろん、私たちはユーザーが提供するファイルを制御しません。異なる量の前処理ステップが必要になります。

私のメッセージハンドラサービスは別々のAPIになっているので、パフォーマンス上の理由から「まだ処理できません」または「処理は必要ありません」を返すために呼び出す必要はありません。

同様に、私はサービス間でアップロードしたファイルを渡したくありません。

理想的には、コンテンツを評価し、理にかなったメッセージハンドラのものだけを挿入することで、ファイルのフローを動的に設計したいと考えています。

私は、AからZへ行くのではなく、Zから始める必要があるステージをチェックし、最後のステージだけを挿入する必要があるので、「反転」パイプラインと言っています。

アップロードされたファイルがすぐにFinalProcessingに適合する場合、フローはただ1つの要素に過ぎません。

ファイルがPreprocessingTwoから行くために必要な場合、その後の流れはそうPreprocessingTwo>PreprocessingThree>FinalProcessing

だろう、私はそのような何かを実装することができます考えていたが、私は詳細について確認していません。

public interface IMessageHandler 
    { 
    void Process(IFile file); 
    } 


public interface IContentEvaluator 
{ 
    IList<IMessageHandler> PrepareWorkflow(IFile file); 
} 

public interface IPipelineExecutor 
{ 
     void ExecuteWorkflow(IList<IMessageHandler> workflow, IFile file); 
    } 

そしてアプリケーション

public void Start(IFile newFile) 
{ 
    var contentEvaluator = new ContentEvaluator(this.availableHandlers); // would be DI 
    var workflow = contentEvaluator.PrepareWorkflow(newFile); 
    this.executor.ExecuteWorkflow(workflow, newFile); 

} 

であなたは、いくつかの助言アプローチを推奨したり、さらにお読みくださいもらえますか?

答えて

2

Strategyパターンを使用することをお勧めします:...実行時にアルゴリズムを選択...
しかし、実装する必要のある戦略の数よりも多くの組み合わせのフローがあると、ソリューションが複雑になる可能性があります。

別のアプローチは、SEDAを使用することができる:...ができる
PreprocessingOne、PreprocessingTwo、PreprocessingThreeとFinalProcessingは段階である...キューによって接続されたステージのセットに複雑な、イベント駆動型アプリケーションを分解し、流れ発信メッセージを異なるキューに送ることによって定義できます。

0

decorator pattern

定義

は動的オブジェクトに追加の責任を添付していることです。 デコレータは、 機能を拡張するためのサブクラス化の柔軟な代替手段を提供します。

関連する問題