Change type constraint of pipeline behavior to allow easier chaining #830
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
We have encountered an interesting "problem" related to the newly introduced PipelineBehavior type constraint in the latest version of the library.
To elaborate a bit, we had a few flag interfaces that were meant to enable certain pipeline behavior based on its type constraints. For example,
ITransactionalRequest
orIScopedRequest
. Such interfaces inheritedIBaseRequest
since response types are not important for the behaviors that use them as type constraints:Such composition made it possible to use
ITransactionalRequest
for any type of request (ieIRequest
,IRequest<TResponse>
), and behavior would be "enabled" no matter whether a request returnsUnit
orTResponse
However due to the subtle change in the type constraint
IPipelineBehavior<TRequest, TResponse> where TRequest : IRequest<TResponse>
it forces library consumers to create pairs of interfaces without real need in my opinion. The above example doesn't work anymore sinceITransactionalRequest
doesn't inherit fromIRequest<TResponse>
so the type can't be inferred. That leaves us with the following fix:The fix itself is not a big deal, but I think if we change the type constraint as proposed in the PR, we would be able to keep the benefits of knowing that pipeline behavior works with known request objects, and we wouldn't force more complex, or generic flag interfaces elsewhere in 3rd party code. After all, that is the intended purpose of
IBaseRequest
interface.I'm curious to hear your opinion, thank you!
PS. I know I haven't asked whether this change is wanted or not, but I wished to cut some corners, hence the PR.