Conveying state object in context

[dls314]

Similar to the CancellationToken, I often need to pass around an object-typed state so that I can satisfy any of the TAP, EAP, APM programming models that clients might desire.

Right now, I'm deriving from PipeContext and adding a state property because "object" is too indiscriminate for the type-keyed Payload functionality in PipeContext/BasePipeContext.

Have you considered a name-keyed Payload functionality? I haven't looked deeply enough to work out what else Payload is being used for, so that might not be practical.

[phatboyg]

I'm trying to understand what you're asking. And why Payload isn't the right solution for you.

First, it's almost always the right solution to create your own XxxContext which includes PipeContext as a base interface type. I have never used PipeContext by itself, it's just the minimal necessary. So creating your own interface with your types on it makes absolute sense.

To the other part, are you saying that Type alone is not unique enough for you to use payload, that you need something more discriminating, such as Type+Key? That was not ever part of the payload design. If you need to key something by a string, you could add that container to the payload, such as IMyBagOfStuff and then use context.GetPayload<IMyBagOfStuff>().GetMyStuff("myId"); to finish it out.

Creating your own context is the proper style, however, and true to Green Pipes design.

[dls314]

Usually I'm using a stream as an implementation behind a method signature like

Task DoSomething(/*...*/, object state, CancellationToken cancellationToken);

There's a good place in the PipeContext for the cancellationToken, but not for state.

Since I expect to derive a specific context for the pipeline behind DoSomething, it's easy to add an intermediate interface PipeContextWithState that DoSomethingPipeContext derives from.