search

rebus-org / Rebus.Events

:bus: Convenient event configuration extensions for Rebus
https://mookid.dk/category/rebus
Other
17 stars 1 forks source link

Make aware of Rebus.ServiceProvider and made the SentStep more like the ReceiveStep #5

Closed EraYaN closed 2 years ago

EraYaN commented 2 years ago

Also modeled the project more after the Rebus.ServiceProvider project. This is sort of related to #2 But it can now do the dependency on Rebus.ServiceProvider without actually being dependent. This lets you access the actual ServiceProvider in the Event handlers, very useful if you want to for example set some user context for the handlers.

Kinda depends on https://github.com/rebus-org/Rebus.ServiceProvider/pull/60 for optimal use.

Rebus is MIT-licensed. The code submitted in this pull request needs to carry the MIT license too. By leaving this text in, I hereby acknowledge that the code submitted in the pull request has the MIT license and can be merged with the Rebus codebase.

mookid8000 commented 2 years ago

Hi @EraYaN , as a matter of principle I don't think the different Rebus integration and utility packages should know about each other. I can understand that this pretty elegant solution does not introduce any additional dependencies or anything, but I think it's kind of "secret" that the Rebus.Events positions its own step in relation to something else if it happens to discover it.

My suggestion is that you solve the problem by extending Rebus for your own usage by creating an IPipeline decorator that moves the steps from Rebus.Events to the right place if you like.

Therefore I am closing this PR. I hope that makes sense to you.

I am very happy that you considered contributing ❤️

EraYaN commented 2 years ago

We'll maintain our own fork for now. It's frankly a bit useless to combine some of these extensions right now, so hence why I figured it should probably be put in a PR.