Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Change type constraint of pipeline behavior to allow easier chaining #830

Merged

Conversation

darjanbogdan
Copy link

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 or IScopedRequest. Such interfaces inherited IBaseRequest since response types are not important for the behaviors that use them as type constraints:

public class TransactionalPipelineBehavior<TRequest, TResponse> : IPipelineBehavior<TRequest, TResponse>
        where TRequest : ITransactionalRequest
{
// implementation
}

Such composition made it possible to use ITransactionalRequest for any type of request (ie IRequest, IRequest<TResponse>), and behavior would be "enabled" no matter whether a request returns Unit or TResponse

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 since ITransactionalRequest doesn't inherit from IRequest<TResponse> so the type can't be inferred. That leaves us with the following fix:

interface ITransactionalRequest<TResponse> : IRequest<TResponse> { }
interface ITransactionalRequest : ITransactionalRequest<Unit> { }

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.

@jbogard
Copy link
Owner

jbogard commented Feb 2, 2023

Yeah I'm not sure the generic constraints really added much except work.

@jbogard
Copy link
Owner

jbogard commented Feb 6, 2023

Sorrryyyyy everyone 😬

@jbogard jbogard merged commit caff80e into jbogard:master Feb 6, 2023
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

2 participants