Refactoring PipelineBehavior as decorator pattern

[rozturac]

I woould suggest refactoring the PipelineBehavior to be the decorator pattern. After this arrangement, I think it will provide the following benefits.

1. Instead of handling exception on each pipeline, we can give this responsibility to the last pipeline.
2. We can set up DistributedLock in our pipeline and interrupt it from going to command (We can do this without throwing an exception)
3. It allows us to access and manipulate the request and response information over the pipe.

By the way, if you agree, I can do this development with pleasure.

[osoykan]

Hi, thanks for the subject, but it is not clear.

Instead of handling exception on each pipeline, we can give this responsibility to the last pipeline.

Could you elaborate on that? It is too vague. Maybe provide an example of your thought as a comment so we can discuss it.

We can set up DistributedLock in our pipeline and interrupt it from going to command (We can do this without throwing an exception)

This is not the library's responsibility to know any application logic. Hence we shouldn't add any behavioral change for this purpose.

It allows us to access and manipulate the request and response information over the pipe.

The current pipeline already gives this possibility.

[rozturac]

Hi, firstly thanks for the response.

I'll try to explain the improvement I'd like to do with the following pseudo code:

Act -> Func (Request) -> Response
Pipe -> Func (req Request, next Act)
Command -> Act

FirstPipe : Pipe {
 try {
    return next(req)
 } catch (ex Exception){
    //we can handle the exception and return anything
 }
}

SecondPipe : Pipe {
    // we can log request
    result = next(req)
    // we can log response with duration
    return result
}

ExecutionResult -> FirstPipe(SecondPipe(Command))

By the way, it seems that the response value is not coming in as-is pipeline.

[osoykan]

I understand what you mean now, It is a good addition; if you would like to add it, could you please target the v2.0 branch?

Also, another PR #34 touches the same area that you want to develop; that PR might be obsolete after the pipeline development.

If you open a PR we can discuss the changes from there.

[rozturac]

Hi thanks for your suggestions. Then, I'll do the development on the 2.0 target and open the PR request as soon as possible.

[rozturac]

Thanks for your issue support and suggestions 🙏