Message Handling Runtime #

Next, even though I said that Wolverine does not require an adapter interface in your code, Wolverine itself does actually need that for its own internal runtime pipeline. To that end Wolverine uses dynamically generated code to "weave" adapter code around your message handler code. It also weaves in the calls to any middleware applied to your system. In ideal circumstances, Wolverine is able to completely remove the runtime usage of an IoC container for even better performance. The end result is a runtime pipeline that is able to accomplish its tasks with potentially much less overhead than comparable .NET frameworks that depend on adapter interfaces.

How Wolverine Consumes Your Message Handlers #

If you're worried about the performance implications of Wolverine calling into your code without any interfaces or base classes, nothing to worry about because Wolverine does not use Reflection at runtime to call your actions. Instead, Wolverine uses runtime code generation with Roslyn to write the "glue" code around your actions. Internally, Wolverine is generating a subclass of MessageHandler for each known message type:

public interface IMessageHandler
{
    Task HandleAsync(MessageContext context, CancellationToken cancellation);
}

public abstract class MessageHandler : IMessageHandler
{
    public HandlerChain? Chain { get; set; }

    public abstract Task HandleAsync(MessageContext context, CancellationToken cancellation);
}

^{snippet source | anchor}

IoC Container Integration #

Wolverine is only able to use Lamar as its IoC container, and actually quietly registers Lamar with your .NET application within any call to UseWolverine(). Wolverine actually uses Lamar's configuration model to help build out its dynamically generated code and can mostly go far enough to recreate what would be Lamar's "instance plan" with plain old C# as a way of making the runtime operations a little bit leaner.