- [New]: Targets .NET Standard 1.3 and .NET Standard 2.0
- [New]:
SyncDispatcher
allowing non asyncSend
,Publish
andRequest
.
- [New]: Targets .NET Standard 1.4 instead of .NET 4.5
- [New]: Added concept of dispatchers with first implementation being
AsyncDispatcher
, which supports:SendAsync
,PublishAsync
andRequestAsync
. - [New]: Added support for simple hooks
OnBeforeRouting
andOnAfterRouted
which SIMPLIFIES using e.g. Autofac scopes for your handlers, as in you do not have to use theMiddlewareEnabledAsyncRouter
anymore to achieve this. - [Breaking]: Renamed:
SequentialAsyncMessageRouter
toSequentialAsyncRouter
. - [Breaking]: Renamed:
MiddlewareEnabledAsyncMessageRouter
toMiddlewareEnabledAsyncRouter
.
With this rewrite, the API is now considered stable and no more breaking changes are planned.
- [Breaking]: Renamed:
MiddlewareEnabledSequentialAsyncMessageRouter
toMiddlewareEnabledAsyncMessageRouter
. - [Breaking]: The
MessageRouteFactory
does not depend on aMessageHandlerCreator
anymore. The creator is instead injected to any of the pre-made routers. - [Breaking]: The routers now accept a
MessageHandlerCreator
. This is where you inject your resolving IoC-container. - [Breaking]: A
MessageRoute
now exposeIMessageHandlerAction[]
instead ofFunc<MessageEnvelope, Task>
- [Breaking]: The resolver that you pass to the
MessageRouteFactory
is now a delegateMessageHandlerCreator
with a signatureobject MessageHandlerCreator(Type messageHandlerContainerType, MessageEnvelope envelope)
. More info in the README.md - [New]: Internally routhing is using a new
MessageEnvelope
. This allows for e.g. hooking in state on a certain message being routed. - [New]: New pre-made router:
MiddlewareEnabledSequentialAsyncMessageRouter
; which allows you to hook into the routing pipe. Similar to Owin.router.Use(next => async envelope => {...});
. More info in the README.md
Now using IL Emits
to get faster calls/routing.
The IL Emits
optimizations allows for a change in resolving the instances of the classes handling the messages. NO MORE SINGLETON, unless you want to. You are in control. Now, the resolving function passed to the MessageRouteFactory
is called when each message is routed. No more singleton behavior. Of course you can accomplish singleton by resolving the same instance each time. This is something you would handle in your IoC-container if that is hooked in.
First release.