How can we improve the retrieval of MessageHandler implementations from the IoC container

[fgheysels]

Not an idea for a new feature, but an idea for a possible improvement.
As mentionned in this PR #260 , the code to retrieve registered IMessageHandler implementations is not that stable. We should find a way to improve this.

@stijnmoreels's comment copied from the mentionned PR:

You'll probably wonder why we have this reflection code in the MessageHandler file.
This is bc we were faced with a problem when implementing the message routing. The IServceProvider doesn't support open generic interfaces and since our IMessageHandler<,> is such an open interface, there is no build-in way to extract all service registrations with a generic message type.
This message handler class will do this for us. It searches for the 'engine' and 'call site factory' on the service provider and extracts all the message handler interfaces. Later on, we can determine if there exists and message handler that can process the incoming message.

We can off course discuss this later, or come up with something else. For now, this was the best we could do. Unfortunately.

I was wondering if we couldn't work around this without using reflection.
Maybe it is an idea to introduce a non-generic interface (empty) IMessageHandler. The IMessageHandler<,> would then derive from that non-generic IMessageHandler interface, like this:

public interface IMessageHandler 
{
}

public interface IMessageHandler<in TMessage, in TMessageContext> : IMessageHandler where TMessageContext : MessageContext
{
     ...
}

The code for retrieving registered message-handlers could then work on retrieving types that are assignable from the base-interface IMessageHandler.
Once we have retrieved those types, then we need of course an additional filter: we only want to take into consideration those types that are also assignable to the IMessageHandler interface which declares type parameters.

[stijnmoreels]

We also don't know the message type before hand. There there would still need some reflection to go from the general one to the concrete. We have also some filters that are used to deserialize and filter on message body and message context, plus, the actual processing method also has the concrete message type in its method.
Maybe, with your proposal, we can improve the first call to the IServiceProvider, but the other ones will have to stay. Also, we have already did some different scenario's on this, so it's somewhat a continuous improvement process 😅 .
Thx for thinking up improvements! 👍

[fgheysels]

I think indeed that in this case, you'll need to apply some reflection. However, If we can find a way to improve that first step, that might already be good, as I do not like to rely on getting properties / fields via reflection of types that we do not own. It's just too fragile, as we are not in control / we do not know when the implementation of that type changes.

[stijnmoreels]

True, very true. Let's have a look together.