Integrate MediatR like middleware directly to DryIoc about dryioc HOT 8 CLOSED

Ok, to this moment I have implemented MediatR ideas, but stripped to the core, to reveal the whole simplicity of it..

Now, after reading Jeremy's take on this I was thinking how to replace an ad-hoc middleware idea with more DI controllable way. And the answer is.. tadah.. Decorator. Middleware is just a special case of decorating the target handler. Then why don't just use a DryIoc decorators explicitly. The main benefit in addition to abstraction cut, would be controlling the order. I can just insert dercorator closer to handler, if I want. Then I have a decorator's condition, reuse, stateless implementation via factory methods, etc. etc.

from dryioc.

*gnoring dislikes..

An improved model for messages may look like this:

interface IMessage<TRequest, TResponse> 
   where TResponse : U<NoResponse, Unit, IResponse<TRequest>> {}

Hmm.. ;-)

from dryioc.

Is it possible to get only some plumbing in DI and retain some implementation in example? I am afraid there should be tests from different domains (enterprise ui, server, desktop console, mobile, games, web sites, value in multi language micro service design) to ensure that messages are good.

May be some code which makes replacing internals of MediatR and other eventing(other case) items with DI easy one step process?

from dryioc.

@dzmitry-lahoda,

Is it possible to get only some plumbing in DI and retain some implementation in example?

My example above was a bit of a joke :) I will be doing the simplest thing possible, so no pressing of Discriminated Unions. It also will be layers of abstraction as discussed in PR, so you can peek your thing.

from dryioc.

efdd045#diff-ecb85472b95ba475d6a564e8951d8baeR10461

from dryioc.

May be add this as md file in documentation instead of releasing? I recall when Unity had mediator as sample in the book or as contrib project. Events are complex beasts with many possibilities regarding threading, order, resource usage, broadcasting, error handling, integration with event loops. So it looks that simplest approach may work in specific set, so experimental namespace would also work.

from dryioc.

I still release it in separate namespace. Easy to point someone to it. Documentation PR is welcome.

from dryioc.

Namespace DryIoc.Messages contains this thingy

from dryioc.